【大话IT】小米双11：海量推送业务如何应对高并发负载？

shang2010 · 发表于 2014-11-18 10:44

1.小米推送服务的服务器端在数据存储上用到了哪些数据库？
sql and nosql，够笼统吧？

2.面对双十一大促，小米的推送消息量剧增，那小米推送(MiPush)服务到底是如何应对这种高并发负载的呢？稳定性又是如何保证的呢？采取了哪些应对方法？比如扩容、异步排队？
前两天给一个非技术行业的人讲技术，也是谈海量服务的话题。
高并发，异步排队这样的高深技术名词是没法讲懂的，我就举例了一个简单例子，搭传奇私服。一台机器再怎么优化就只能抗这些了；如要面对海量的用户，在各地各区域，管方就要搭建了很多私服——直接分散面对海量服务。但是在后台又在做同步工作。有些技术是没有后台数据同步的，有些是有数据同步的。
说到这个话题，我提炼就三个字，【搭私服】，你们所有的技术都在围绕，如何搭建更多的私服。所有的花头都大同小异。

3.小米推送服务的软件系统经历了两次重构，一是将开发语言从Erlang转为了Java,请问这有什么好处？而是对调用频繁的业务添加Cache，请发挥您的想象谈谈Cache的实际应用。
cache是直接放在内存的数据，比从磁盘访问更快。cache是非常有效的优化办法，例子太多了。

4.安全性也是小米推送服务重点考虑的一个因素，小米在推送服务中是如何确保安全新的呢？
我很少相信安全性，不是你处于不安全，就是我处于不安全。要谈确保，似乎口气太大了

华夏小卒 · 发表于 2014-11-18 10:47

小米推送服务共发出9.65亿条消息，平均每分钟发送67万条

1、每秒钟也就才11000条消息。如果横向扩展的N倍的话，可能一台机器每秒也就11000/N 不到。
2、而且对于这些订单，基本都是唯一的记录。在获取信息上，都非常快。
3、订单方面的数据，都是每天进行归档，当天的表里没有多少数据。
4、从客户方面来看，订单信息，也不是下单瞬间，立马消息到达客户。

不知道说的对不对