UNPKG

fox-wamp

Version:

Web Application Message Router/Server WAMP/MQTT

github.com/kalmyk/fox-wamp

kalmyk/fox-wamp

58 lines (38 loc) • 2.72 kB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
# demo easy start ## resource-lock.supervisord.ini three clients that lock resource for the 5 second each, so the next able to lock the resource after the previous release it - to start: ```shell $ supervisord -c ./resource-lock.supervisord.ini ``` ## masterfree.supervisord.ini masterfree band queue work - to start: ```shell $ supervisord -c ./masterfree.supervisord.ini ``` # blueprint Yes, I know about snowflake-id DateTime + Segment + Offset + [ Shard * ProcessingStep ] advanceId {segment, offset} advanceId.segment - nearly random string value advanceId.offset - offset inside the segment entry When message arrived, unique advance-id is created. Roundrobin creates partition-id. With that destination partition id is generated by round-robin. The message and all messages comming after that are signed by that advance-id and sequence number. The begin-advance-segment is sent to all sync hosts and ndb-storages. Messages bodies are sent to all corresponding destination storage hosts with keep-advance-history message. at trim-advance-segment message the entry collects votes from storage copies. when trim-advance-segment elected the advance-segment is completed and advance-segment-over message is sent to destination storage host. New advance-segment will be generated at the next inbound message. for next advance id all not resolved items are sent to the next shard in creation order. that must keep inbound order when shard is changed. advance-segment-resolved message arrived when advance-id become permanent identifier. At that time entry able to send ACK message for messages with permanent id. ndb-storage when begin-advance-segment arrived, the trim-advance-segment message is generated immidiatelly to terminate segment at entry. arriving inbound messages in keep-advance-history are stored temporary with advance-id marker. when advance-segment-resolved arrived the temporary storage is moved to permanent. advance-segment-over event starts permanent id election procedure sync the sync cluster is responsible to transform nearly random advance-id to monotonic id. entry ndb sync begin-advance-segment -> keep-advance-history -> <- trim-advance-segment advance-segment-over -> makeSegmentId -> generate mew time+genId for tmp-id send to next sync stage vote, take low _in_vouter_ time+genId for tmp-id send to final sync stage