the function realization of small aquamarine data push service technology
After 11.11, with the rapid increase of mobile traffic, the basic services such as Xiaomi's push are also undergoing great tests. On November 12, Xiaomi's project director, Wang Xuan, announced on Weibo that "the Xiaomi push service sends out 965 million messages, averaging 670,000 per minute." It is worth mentioning that the background monitoring shows that the push service backend system operates very smoothly throughout the day, there is no lag congestion phenomenon, so that a variety of promotional, rebate, order update message The first time to reach the user. ”
Wang Xuan, who graduated from the computer department of Tsinghua University in 2007, joined the Microsoft Institute for Asian Engineering and was involved in the development of the browser on WP7. Joined Xiaomi in July 2010 as a team leader in the rice chat Android team and is now the project director at Xiaomi, responsible for Xiaomi developer Services, in charge of the three business of push service, statistical services and mobile Advertising Alliance, aiming to build a mobile app business Internet ecosystem for Xiaomi.
We contacted Wang Xuan, on the structure, characteristics, performance and other issues of the Xiaomi push service, he was interviewed, the following content according to this interview organized.
Basic Technology Architecture protocol is at the heart of the push service. The protocol used by Xiaomi's push service evolved from the previous chat, while the development team made several rounds of streamlining and refactoring the XMPP protocol from the outset by choosing to use the XMPP protocol. Now the XMPP part is just as a transmission layer of data, running on a variety of independent business, each business is called a "channel"; The data format that runs on each channel can be different. The message push service is one of the channel, and the data transmitted on the channel is a binary protocol format via thrift.
Take a look at the service-side architecture of Xiaomi's push service. is a basic architecture diagram of the backend server. The entire server consists of the following layers:
XMPP front end: Used to maintain a long connection to the client, use the Ejabberd project to process XMPP requests from the client, and handle the XMPP message protocol specific to the push service through the XMQ module.
Middle tier: The business logic layer, which is primarily used to asynchronously request message requests, create and maintain message queues, and handle some command requests (registration, alias setting, setting topic, and so on) of the client.
HTTP frontend: This layer is responsible for interfacing HTTPS requests for messages from servers in third-party apps, and HTTPS requests from client-generated accounts.
There is data storage, the use of Xiaomi's unified hbase storage, while also using MySQL to save some small, but need complex filtering conditions of data (topic, etc.), and in order to reduce the pressure on hbase, in the middle also added a layer of redis as a cache.
Finally look at the client schema. The client SDK consists of two levels: the SDK layer and the Pushservice layer. The former provides an interface for app access, callback methods, and processing logic to deserialize data from thrift, which is used to maintain XMPP long connections and send and receive messages. The intent method is used to transfer data between the two tiers. It is worth mentioning that on the MIUI system, the Pushservice layer is shared by the system, that is, the MIUI system provides a unified Pushservice management module that does not require each application to start its own pushservice individually.
function ImplementationXiaomi push service supports both single and bulk message push methods. Single message support for Regid and alias two ways, Regid is Xiaomi push service background based on the device identification +appid+ timestamp generation, in order to reduce the device collision probability, equipment identification we use the basis is the Imei+androidid+build serial number. Alias is the app in the client settings escalated, easy to apply their own device/user identifier with our regid, so that the app does not need to maintain regid in the background with the device/user relationship. Mass message using the way to distinguish between the label, the client and the server can be assigned to the specified device label, send a message, just select the designated label to send, Xiaomi push the background will be the corresponding device to expand the label. There is no limit on the number of devices supported by a tag.
How is the stability of Xiaomi push service guaranteed? Xiaomi push service using multi-room program, peacetime flow averaging, once a room failure, the flow of seamless switch to other room, and the capacity of a single room can guarantee the provision of non-destructive services. is currently a two-room deployment, is expected to expand the third room next year.
Security is also a key consideration for Xiaomi push services. In the process of data transmission, thanks to the double-layer protocol scheme adopted by push service, the message will take double encryption, the first is XMPP transport layer, ensure that the data will not be tampered with and monitored during the transmission of the network. The second weight is in the thrift binary layer, to ensure that the message arrives at the service, through the broadcast sent to the app process will not be intercepted and forged. Second-order encryption is often ignored by other third-party push services, but the risk is equally large.
Performance Index11.11 Big Promotion, the face of the demand is in the Xiaomi push service design capacity, the current design and machine size can support peak 10 million messages per minute, the usual traffic at least 400,000 per minute, peak per minute 6 million messages.
The volume of push messages fluctuates very often, so the development team prepares for a 200% increase in traffic at any time, and does stress testing and optimization on-line, and if the traffic is particularly large, the following countermeasures are also available:
1. Asynchronous queue processing, when the message delivery time may be slightly slower than usual, but will not have a large impact on the whole system;
2. Messages are prioritized and broadcast messages are processed with low priority;
3. Limit the current, control the frequency of the developers to send messages;
4. Capacity expansion, if the machine load is too high or a service bottleneck, can quickly increase the machine, deployment services, enhance the system processing capacity.
re-construction of Xiaomi's push service experienceIn the process of development and evolution, software systems often undergo a larger scale reconstruction. Xiaomi push service has more than two times the larger refactoring.
The first is that the development language is converted from Erlang to Java. Xiaomi's original messaging system was developed using Erlang, so the first version of the push system was also Erlang-based, but the Erlang community was not active, the developers were hard to find, the learning curve was steep, and the support tools and libraries were few, so the development team chose to use Java to re-develop , after migrating to Java, the requirements for developers are reduced, and the tools and libraries are many, which greatly improves the development efficiency.
The second is the ubiquitous cache. The client uses the Xiaomi Push Service SDK, the developer uses the API the situation to be changeable, many scenes are unexpected, needs to add the cache to the frequent call business, as far as possible within the local process, for example, for the client call API setting alias and subscription topic, First check that the cache has been set, only if there is no setting to send back-end service, after optimization, the business pressure of the backend service is greatly reduced.
some insights in the development of millet push process
Services to support horizontal scaling, as far as possible to be stateless, or use a consistent hash of the partition, easy to expand, to ensure that even if the system temporarily has a performance bottleneck can be solved by adding machines.
Monitoring first, can easily collect, analyze server load and business request volume, percentile, slow log, can clearly understand the bottleneck of the system, targeted improvement.
Do not optimize early, implement functions and go online as soon as possible, and optimize key locations based on monitoring data.
Agile development, rapid iteration, daily arch, a short standing meeting every day, can quickly respond to changes, continuous improvement of the system.
The function realization of millet massive data push service technology
