Gopush-cluster Architecture

This is a creation in Article, where the information may have evolved or changed.

Objective

Gopush-cluster is a set of golang development of real-time message push cluster, the main share of the development of this system of ideas and ideas.

Architecture

Mainly divided into three modules to develop, comet/web/message.

Comet

Mainly responsible for Message Queuing, message push and connection maintenance with the client; the whole system is based on the message ID sequence principle to get the message (the client gets the maximum message locally is 1, then the message is more than 1, the time to get offline messages from the last maximum message ID to obtain), As a result, message pushes need to be queued in comet and then RPC is sent to the message for storage.

Message

It is primarily responsible for storing and reading messages, accepting messages from comet modules for persistence, or accepting read messages from web modules to request offline messages. The message is that multiple nodes can be deployed to load push pressure from a large number of comet, such as different comet using different message nodes (node stateless), and then the load-balancing RPC call and failover (TODO) for the message node in comet.

Web

Mainly responsible for node inquiry, as well as offline message acquisition and background node management, etc. the node query is mainly based on the client's subscription key consistency hash to calculate the connected Comet node address, so the massive client connection can be scattered to multiple comet to serve In addition, offline messages are returned to the client through the Web interface, but the messages are sent to the message module via RPC, with the sole responsibility of doing so. Web nodes because of a stateless state, you can deploy multiple Web to achieve load balancing and failover.

Thrid-part

The message store now relies primarily on REDIS for message read and write (Sorted set) because Sorted set does not support score of int64 types (we have also developed a branch that supports int64 score but because time is not a lot of testing on-line), The HBase cluster may then be used instead of Redis, providing a more secure offline message store (TODO).

Another use of the zookeeper to achieve the same comet failover, such as Comet Node 1 can have an alternative node node 2, when node 1 is registered to zookeeper, because the machine or other reasons for the outage, At this time, the zookeeper will be triggered in the Web layer of the election selected node service.

Conclusion

Gopush-cluster the approximate architecture and then writes the details of the other modules, as well as the optimizations and problems encountered.

Article reprint address: http://www.cnblogs.com/bhtfg538/p/3585406.html