小米3抢购软件文章列表:

• 1、小米推出亿万秒杀活动，5月11日至18日，每天3场大牌特价秒
• 2、小米mixfold三款型号价格分别是多少 小米mixfold预售抢购方法介绍
• 3、小米有品开售 53 度飞天茅台：每瓶 1499 元，人脸识别验证资格
• 4、小米手机越来越容易抢的背后：抢购系统的优化
• 5、带你五分钟解读：小米网电商异步消息系统的实践

小米推出亿万秒杀活动，5月11日至18日，每天3场大牌特价秒

5月13日消息，近年来随着拼多多率先推出“百亿补贴”活动以来，吸引了大量的消费者的眼球，淘宝、京东、苏宁等电商平台也纷纷推出补贴活动，给消费者带来了很多的实惠。现在小米有品也推出了“亿万秒杀”活动，并且补贴的商品全部都是大牌，价格低至你完全不用去比价。

据悉，小米有品的“亿万补贴”活动是从5月11日正式开始的，每天秒杀1000件大牌商品，并且保证大牌正品，完全不用比价，先预约后秒杀，先到先得。大家可在小米有品APP内直接搜索“亿万补贴”就能进行预约抢购了，从5月11日至18日，每天有3场抢购，分别在10点、16点、21点，准时开抢。

小米有品是小米旗下的电商平台，于2017年4月成为独立APP上线，主打“精选”概念，为消费者带来品质高、颜值高、性价比高的优质商品。根据曝光的信息显示，小米有品这次的“亿万补贴”活动，包括国行Switch 1599元、AirPods 2 759元、小米手环4 NFC版99元、迪奥999口红99元等等。

感兴趣的小伙伴可至小米有品APP内直接搜索“亿万补贴”就能直接参与抢购活动了。

本文编辑：NJNR205

小米mixfold三款型号价格分别是多少 小米mixfold预售抢购方法介绍

小米mixfold作为小米官方发布的首款折叠屏手机，受到了不少小伙伴的关注，不少用户都在好奇小此款手机到底什么时候开售？这不，4.7日就已经在京东开启了发售，想抢购的用户千万不要错过以下内容哦~

小米mixfold价格

此款手机分为三款型号，价格分别为：小米 MIX FOLD 标准版 12 256GB为9999 元，12 512GB为10999 元，陶瓷特别版，模拟凯芙拉纹理，16 512GB价格最高为 12999 元。

小米mixfold预售抢购方法

此次小米率先在京东开启了全款预售、全国有货，想要购买的用户可以按如下步骤提前预定，等4月16日正式发布便会直接邮寄给大家。

1、打开京东app，在首页点击上方搜索框。

2、输入“小米mixfold”进入搜索（不想打字的用户可以直接复制小编的手机文字哦）

3、认准官方自营店进入，点击商品详情页下方“立即抢购”即可预订成功。

看了这么多，你学会了吗？超详细的演示，学习的事怎么能白嫖呢，快来IE浏览器中文网站点个关注吧！

来源：IEfans

小米有品开售 53 度飞天茅台：每瓶 1499 元，人脸识别验证资格

IT之家10月23日消息 今日，小米有品在 App 内开启 53 度飞天茅台购买预约，500ml 装售价 1499 元。

页面规则显示，用户在工作日上午 10:30 可参与预约 ，预约成功后于次日 10 点开始抢购。目前处于预约阶段，下周一 10 月 26 日开放第一批购买。

IT之家了解到，为防止黄牛刷单抢货，预约环节需通过人脸识别进行资格验证，同一用户 30 内最多购买 2 瓶，每次限购 1 瓶。抢购成功的用户需在 1 小时内支付，超过有效期将被取消购买资格。

物流运输方面，商品将在支付成功后 48 小时内发出，用户收货时需持有效证件当面拆箱验货。如遇节假日，预约及发货周期自动顺延。

除飞天 53 度飞天茅台外，小米有品将同时供应 43 度飞天茅台、茅台王子酒、茅台迎宾酒、赖茅、贵州大曲、茅台醇、茅源、习酒以及茅台生肖酒、茅台老酒等产品。据介绍，在之后的双 11 活动中，小米有品还将加大茅台投放量，辅以黄牛识别防控技术。

53 度飞天茅台：点击购买

小米手机越来越容易抢的背后：抢购系统的优化

我和同事们对小米网的抢购系统做了最后的检查与演练。几个小时后，小米网今年开年来最重要的一次大型活动“米粉节”就要开始了。

这次米粉节活动，是小米电商的成人礼，是一次重要的考试。小米网从网站前端、后台系统、仓储物流、售后等各个环节，都将接受一次全面的压力测试。

10点整，一波流量高峰即将到来，几百万用户将准点挤入小米网的服务器。而首先迎接压力冲击的，就是挡在最前面的抢购系统。

而这个抢购系统是重新开发、刚刚上线不久的，这是它第一次接受这样严峻的考验。

系统能不能顶住压力？能不能顺畅正确地执行业务逻辑？这些问题不到抢购高峰那一刻，谁都不能百分百确定。

9点50分，流量已经爬升得很高了；10点整，抢购系统自动开启，购物车中已经顺利加入了抢购商品。

一两分钟后，热门的抢购商品已经售罄自动停止抢购。抢购系统抗住了压力。

我长舒一口气，之前积累的压力都消散了。我坐到角落的沙发里，默默回想抢购系统所经历的那些惊心动魄的故事。这可真是一场很少人有机会经历的探险呢。

抢购系统是怎样诞生的

时间回到2011年底。小米公司在这一年8月16日首次发布了手机，立刻引起了市场轰动。随后，在一天多的时间内预约了30万台。之后的几个月，这30万台小米手机通过排号的方式依次发货，到当年年底全部发完。

然后便是开放购买。最初的开放购买直接在小米的商城系统上进行，但我们那时候完全低估了“抢购”的威力。瞬间爆发的平常几十倍流量迅速淹没了小米网商城服务器，数据库死锁、网页刷新超时，用户购买体验非常差。

市场需求不等人，一周后又要进行下一轮开放抢购。一场风暴就等在前方，而我们只有一周的时间了，整个开发部都承担着巨大的压力。

小米网可以采用的常规优化手段并不太多，增加带宽、服务器、寻找代码中的瓶颈点优化代码。但是，小米公司只是一家刚刚成立一年多的小公司，没有那么多的服务器和带宽。而且，如果代码中有瓶颈点，即使能增加一两倍的服务器和带宽，也一样会被瞬间爆发的几十倍负载所冲垮。而要优化商城的代码，时间上已没有可能。电商网站很复杂，说不定某个不起眼的次要功能，在高负载情况下就会成为瓶颈点拖垮整个网站。

这时开发组面临一个选择，是继续在现有商城上优化，还是单独搞一套抢购系统？我们决定冒险一试，我和几个同事一起突击开发一套独立的抢购系统，希望能够绝境逢生。

摆在我们面前的是一道似乎无解的难题，它要达到的目标如下：

只有一周时间，一周内完成设计、开发、测试、上线；

失败的代价无法承受，系统必须顺畅运行；

抢购结果必须可靠；

面对海量用户的并发抢购，商品不能卖超；

一个用户只能抢一台手机；

用户体验尽量好些。

设计方案就是多个限制条件下求得的解。时间、可靠性、成本，这是我们面临的限制条件。要在那么短的时间内解决难题，必须选择最简单可靠的技术，必须是经过足够验证的技术，解决方案必须是最简单的。

在高并发情况下，影响系统性能的一个关键因素是：数据的一致性要求。在前面所列的目标中，有两项是关于数据一致性的：商品剩余数量、用户是否已经抢购成功。如果要保证严格的数据一致性，那么在集群中需要一个中心服务器来存储和操作这个值。这会造成性能的单点瓶颈。

在分布式系统设计中，有一个CAP原理。“一致性、可用性、分区容忍性”三个要素最多只能同时实现两点，不可能三者兼顾。我们要面对极端的爆发流量负载，分区容忍性和可用性会非常重要，因此决定牺牲数据的强一致性要求。

做出这个重要的决定后，剩下的设计决定就自然而然地产生了：

技术上要选择最可靠的，因为团队用PHP的居多，所以系统使用PHP开发；

抢资格过程要最简化，用户只需点一个抢购按钮，返回结果表示抢购成功或者已经售罄；

对抢购请求的处理尽量简化，将I/O操作控制到最少，减少每个请求的时间；

尽量去除性能单点，将压力分散，整体性能可以线性扩展；

放弃数据强一致性要求，通过异步的方式处理数据。

最后的系统原理见后面的第一版抢购系统原理图（图1）。

图1 第一版抢购系统原理图

系统基本原理：在PHP服务器上，通过一个文件来表示商品是否售罄。如果文件存在即表示已经售罄。PHP程序接收用户抢购请求后，查看用户是否预约以及是否抢购过，然后检查售罄标志文件是否存在。对预约用户，如果未售罄并且用户未抢购成功过，即返回抢购成功的结果，并记录一条日志。日志通过异步的方式传输到中心控制节点，完成记数等操作。

最后，抢购成功用户的列表异步导入商场系统，抢购成功的用户在接下来的几个小时内下单即可。这样，流量高峰完全被抢购系统挡住，商城系统不需要面对高流量。

在这个分布式系统的设计中，对持久化数据的处理是影响性能的重要因素。我们没有选择传统关系型数据库，而是选用了Redis服务器。选用Redis基于下面几个理由。

首先需要保存的数据是典型的Key/Value对形式，每个UID对应一个字符串数据。传统数据库的复杂功能用不上，用KV库正合适。

Redis的数据是in-memory的，可以极大提高查询效率。

Redis具有足够用的主从复制机制，以及灵活设定的持久化操作配置。这两点正好是我们需要的。

在整个系统中，最频繁的I/O操作，就是PHP对Redis的读写操作。如果处理不好，Redis服务器将成为系统的性能瓶颈。

系统中对Redis的操作包含三种类型的操作：查询是否有预约、是否抢购成功、写入抢购成功状态。为了提升整体的处理能力，可采用读写分离方式。

所有的读操作通过从库完成，所有的写操作只通过控制端一个进程写入主库。

在PHP对Redis服务器的读操作中，需要注意的是连接数的影响。如果PHP是通过短连接访问Redis服务器的，则在高峰时有可能堵塞Redis服务器，造成雪崩效应。这一问题可以通过增加Redis从库的数量来解决。

而对于Redis的写操作，在我们的系统中并没有压力。因为系统是通过异步方式，收集PHP产生的日志，由一个管理端的进程来顺序写入Redis主库。

另一个需要注意的点是Redis的持久化配置。用户的预约信息全部存储在Redis的进程内存中，它向磁盘保存一次，就会造成一次等待。严重的话会导致抢购高峰时系统前端无法响应。因此要尽量避免持久化操作。我们的做法是，所有用于读取的从库完全关闭持久化，一个用于备份的从库打开持久化配置。同时使用日志作为应急恢复的保险措施。

整个系统使用了大约30台服务器，其中包括20台PHP服务器，以及10台Redis服务器。在接下来的抢购中，它顺利地抗住了压力。回想起当时的场景，真是非常的惊心动魄。

第二版抢购系统

经过了两年多的发展，小米网已经越来越成熟。公司准备在2014年4月举办一次盛大的“米粉节”活动。这次持续一整天的购物狂欢节是小米网电商的一次成人礼。商城前端、库存、物流、售后等环节都将经历一次考验。

对于抢购系统来说，最大的不同就是一天要经历多轮抢购冲击，而且有多种不同商品参与抢购。我们之前的抢购系统，是按照一周一次抢购来设计及优化的，根本无法支撑米粉节复杂的活动。而且经过一年多的修修补补，第一版抢购系统积累了很多的问题，正好趁此机会对它进行彻底重构。

第二版系统主要关注系统的灵活性与可运营性（图2）。对于高并发的负载能力，稳定性、准确性这些要求，已经是基础性的最低要求了。我希望将这个系统做得可灵活配置，支持各种商品各种条件组合，并且为将来的扩展打下良好的基础。

图2 第二版系统总体结构图

在这一版中，抢购系统与商城系统依然隔离，两个系统之间通过约定的数据结构交互，信息传递精简。通过抢购系统确定一个用户抢得购买资格后，用户自动在商城系统中将商品加入购物车。

在之前第一版抢购系统中，我们后来使用Go语言开发了部分模块，积累了一定的经验。因此第二版系统的核心部分，我们决定使用Go语言进行开发。

我们可以让Go程序常驻内存运行，各种配置以及状态信息都可以保存在内存中，减少I/O操作开销。对于商品数量信息，可以在进程内进行操作。不同商品可以分别保存到不同的服务器的Go进程中，以此来分散压力，提升处理速度。

系统服务端主要分为两层架构，即HTTP服务层和业务处理层。HTTP服务层用于维持用户的访问请求，业务处理层则用于进行具体的逻辑判断。两层之间的数据交互通过消息队列来实现。

HTTP服务层主要功能如下：

进行基本的URL正确性校验；

对恶意访问的用户进行过滤，拦截黄牛；

提供用户验证码；

将正常访问用户数据放入相应商品队列中；

等待业务处理层返回的处理结果。

业务处理层主要功能如下：

接收商品队列中的数据；

对用户请求进行处理；

将请求结果放入相应的返回队列中。

用户的抢购请求通过消息队列，依次进入业务处理层的Go进程里，然后顺序地处理请求，将抢购结果返回给前面的HTTP服务层。

商品剩余数量等信息，根据商品编号分别保存在业务层特定的服务器进程中。我们选择保证商品数据的一致性，放弃了数据的分区容忍性。

这两个模块用于抢购过程中的请求处理，系统中还有相应的策略控制模块，以及防刷和系统管理模块等（图3）。

图3 第二版系统详细结构图

在第二版抢购系统的开发过程中，我们遇到了HTTP层Go程序内存消耗过多的问题。

由于HTTP层主要用于维持住用户的访问请求，每个请求中的数据都会占用一定的内存空间，当大量的用户进行访问时就会导致内存使用量不断上涨。当内存占用量达到一定程度（50%）时，Go中的GC机制会越来越慢，但仍然会有大量的用户进行访问，导致出现“雪崩”效应，内存不断上涨，最终机器内存的使用率会达到90%以上甚至99%，导致服务不可用。

在Go语言原生的HTTP包中会为每个请求分配8KB的内存，用于读缓存和写缓存。而在我们的服务场景中只有GET请求，服务需要的信息都包含在HTTP Header中，并没有Body，实际上不需要如此大的内存进行存储。

为了避免读写缓存的频繁申请和销毁，HTTP包建立了一个缓存池，但其长度只有4，因此在大量连接创建时，会大量申请内存，创建新对象。而当大量连接释放时，又会导致很多对象内存无法回收到缓存池，增加了GC的压力。

HTTP协议是构建在TCP协议之上的，Go的原生HTTP模块中是没有提供直接的接口关闭底层TCP连接的，而HTTP 1.1中对连接状态默认使用keep-alive方式。这样，在客户端多次请求服务端时，可以复用一个TCP连接，避免频繁建立和断开连接，导致服务端一直等待读取下一个请求而不释放连接。但同样在我们的服务场景中不存在TCP连接复用的需求。当一个用户完成一个请求后，希望能够尽快关闭连接。keep-alive方式导致已完成处理的用户连接不能尽快关闭，连接无法释放，导致连接数不断增加，对服务端的内存和带宽都有影响。

通过上面的分析，我们的解决办法如下。

在无法优化Go语言中GC机制时，要避免“雪崩效应”就要尽量避免服务占用的内存超过限制（50%），在处于这个限制内时，GC可以有效进行。可通过增加服务器的方式来分散内存压力，并尽力优化服务占用的内存大小。同时Go 1.3也对其GC做了一定优化。

我们为抢购这个特定服务场景定制了新的HTTP包，将TCP连接读缓存大小改为1KB。

在定制的HTTP包中，将缓存池的大小改为100万，避免读写缓存的频繁申请和销毁。

当每个请求处理完成后，通过设置Response的Header中Connection为close来主动关闭连接。

通过这样的改进，我们的HTTP前端服务器最大稳定连接数可以超过一百万。

第二版抢购系统顺利完成了米粉节的考验。

总结

技术方案需要依托具体的问题而存在。脱离了应用场景，无论多么酷炫的技术都失去了价值。抢购系统面临的现实问题复杂多变，我们也依然在不断地摸索改进。

简历又被刷了，应届程序员简历就该这么写

了解常用缓存淘汰算法，这就够了

带你五分钟解读：小米网电商异步消息系统的实践

为了适应业务的高速发展，小米网的系统架构经历了很多次变更。在此过程中，为了给各个子系统解耦合，同时保证最终一致性原则的实现，我们建立了自己的异步消息系统——Notify异步消息系统。

小米网架构发展

小米网的发展大致可以分为三个阶段：初创阶段、发展阶段、完善阶段。

1. 初创阶段

当小米推出自己的第一部手机时，为了减少渠道成本，我们开始推行电商直销的商业模式，与此同时，开始建设小米电商网站。最开始，小米的业务特点是：

SKU(商品品类)单一；

订单量巨大；

瞬时访问量巨大。

后两点是在最初设计系统时完全没有想到，因为当前我们并没有预料到小米手机会如此受欢迎和供不应求。

在这个阶段，快速上线是第一目标，因为团队需要快速配合公司的手机销售计划。所以一开始小米网的架构设计比较简单，并没有考虑高并发和大数据的情况。当时系统从立项到上线仅两个多月时间，并且只由三名工程师开发完成。

图1 小米电商初期的系统架构

从图中可以看出，系统架构只有两个Web服务器与一个DB服务器，两台Web服务器互为主备，所有的业务功能集成在一个系统中。当时的架构设计仅能支持简单的电商功能，我们预测每年的手机销量能到30万就已经很好了。但是计划永远赶不上变化，很快小米电商就遇到了第一个大问题：系统耦合度很高，导致当抢购活动开始时，其他业务都会受到影响。

2. 发展阶段

为了解决上面的问题，需要对小米网的架构进行修改，把各种业务系统拆成独立的子系统。这一时期小米电商的系统架构发展的特点是：

业务系统的拆分，小米负责处理抢购请求的大秒系统就是在这一阶段诞生的，将抢购业务带来的系统压力完全隔离开来，确保在抢购活动时小米的其他业务可以不受影响；

小米的系统结构SOA（面向服务的软件结构）化，小米各系统之间的通信采用接口方式来实现，甚至我们开发了一套通信协议，叫做X5协议，来规范接口的开发与调用。

这一阶段小米网的架构如下图所示：

图2 小米电商发展阶段的系统架构

从图2可以看出，前端与后端系统完全独立出来，当前端进行抢购活动时，后端的客服、售后、物流三大服务系统不会受到任何影响。图2中所列举的子系统只是小米网中的一小部分较为主要的系统，还有很多业务没有列举出来。

这种系统架构可以确保系统之间不会受到影响，但是接口的稳定性就成了一个至关重要的问题。这种系统架构几乎所有的接口都是同步接口，意思就是说一个业务调用这些接口如果不成功，业务也无法成功。如果出现网络问题或者接口BUG，就会导致大量业务失败。但事实上，并非所有的接口都必须做成同步性的，有些业务比如订单系统把订单信息发给仓储系统生产，就对同步性的要求不是很高，可以考虑使用异步方式来解决。为了解决这个问题，小米网架构下一步的演化就是建立一个异步消息队列系统。

3. 完善阶段

经过异步消息系统的引入，小米网的系统架构最终发生了变化，如图3所示：

图3 小米网的系统架构

从图3可以看出，异步消息队列成了一个中心节点，几乎所有的子系统都与它有单向或者双向的交互。当一个业务需要调用一个接口时，如果他对实时性的要求不是特别高，就可以把消息发到我们的异步消息队列系统，然后他就可以完成这项业务，而之后的消息投递过程就完全交给消息队列系统来实现。经过这次调整之后，小米网基本实现了主要业务的异步化，大大增加了系统的容错性，因为所有投递不成功的消息都可以保存在消息队列系统中等待下次投递。

Notify消息系统的设计

基于对上面业务变化的分析，小米网内部开始计划建立自己的异步消息系统。我们对比了市面的几款MQ软件，最后决定以Redis队列为基础，开发自己的异步消息队列系统，取名叫做Notify异步消息系统。

Notify消息系统的设计需要解决以下几个问题：

如何接收消息；

如何存储消息；

如何投递消息；

对消息的统计与监控。

我们采用接口的方式来接收业务系统的消息，采用MySQL来存储消息，在消息发送时使用Redis队列来存储。

为了实现以上主要功能，为Notify系统设计了以下的数据结构。下面为五个最主要的数据表，以及重要的字段：

1. biz - 业务（生产者）；

2. receive - 接收者（消费者）；

3. biz_receive - 订阅关系；

状态字段，表示订阅关系的运行状态，分为正常、暂停（接收消息，但不发送）、废弃（不接收消息）三种。

接口地址字段。

4. biz_msg - 业务消息；

消息体字段。

5. receive_msg - 投递消息；

发送状态字段，分为四种状态，待处理、待投递、已投递、丢弃。

发送次数字段。

这里需要提一下Notify系统的消息分裂机制。考虑到有可能在一项业务执行过程中需要把消息发给多个接口，Notify消息在设计的时候引入了一个消息分裂的概念。

图4 Notify消息设计中的三种消息分裂情况

图4分别列举了消息分裂的三种情况。首先第一种，在没有消息队列时直接调用接口的情况，一个业务执行时如果要将一个消息传递给不同的系统时，就需要调用不同的接口，并且这些接口还必须都返回成功，才能算这个业务执行成功。第二种情况是引入消息队列来处理这个问题的话，如是不进行分裂处理的话，S1需要把同一个消息塞到不同的消息队列里去。也就是要多次将消息发送给Notify系统。这样设计虽然可以确保业务执行成功，但是却不具备扩展性。假设我们新建立一个系统，也需要同样的消息，那么就不得不回过头来修改代码，关闭一个系统也是同理。所以第三种情况中我们设立了一个消息分裂与订阅的机制，业务执行时只需要把消息投递到Notify系统一次，而其他系统如果需要这个消息，就可以在我们的Notify系统中设置订阅关系，同样的消息就被复制成多个副本，然后被塞到多个不同的消息队列来投递。这样做既可以进一步提高业务执行的成功性，又使得业务具备可扩展性与可配置性。

图5 Notify的架构设计

基于上面的一系列设计思想，最终形成了图5中的结构设计图，即Notify系统的最初设计图。我们通过Api.notify接口，来收集业务系统的消息，并存放在DB中。发送消息时，我们设立一个Maker组件，这个组件采用多进程执行方式，对每一个订阅关系开启一个进程，把消息复制一个副本并放到对应的RedisMQ中。MQ的名称就以biz-receive的对应id组合而成，方便查找。然后，我们设立了一个Sender组件，Sender主要完成两样工作：一是把消息发送给对应的业务系统；二是把消息放到Marker Queue中，来回写消息的状态。如果消息发送成功了，就把消息的状态回写成已投递，如果发送失败，就把消息状态重新回写成待处理，以便下一个周期再次投递。然后我们又设立了一个Marker程序，来异步的读取Marker Queue里的消息来回写状态。这样就完成了一个投递周期，整个Notify系统就是通过这种方式源源不断的将消息投递给各业务系统。

除了上面的主要结构外，在实现Notify时，还引入了以下几个特性：

消息分裂，如上文介绍过的一样。

冷库备份功能。随着业务的扩展，DB中的消息数也增长的很快，如果不对DB中的消息做备份，会影响Notify本身的性能，以及统计功能的可用性。对于已经投递成功的消息来说，大部分情况下不会被用到，所以需要定期对消息做迁移冷库的操作。

为了保证发送消息的时效性，对Maker与Sender进行了多进程编程，每个进程负责一个订阅关系的处理，可以独占一个MQ的控制权，我们通过这种方式来提高消息发送的时效性，确保关键业务消息不会被阻塞。

消息重发功能。如果消息发送失败，会被Marker重新标记成待处理状态，以进入下一次的投递周期，同时消息的发次数会加1。每次投递都间隔一定的时间，当投递次数超过一个阈值时，就不再投递了。因为这个时候可能是由于业务系统的接口出了什么问题，再尝试投递没有任何意义，还会造成网络流量的浪费，影响其他系统的业务，所以停止继续投递。待接口问题修复后，我们再手动批量重推消息。

采用异步方式，在投递周期中，也用到了异步思想，这样做也是为了加快消息投递的时效。

消息可查询。Notify为小米网的其他工程师提供了一个可以查询消息体及返回的地方，方便我们工程师调试系统，定位bug。

Notify消息系统的升级变迁

第一版Notify消息系统设计的时候还存在着很多不足与考虑不周之处。随着业务的发展，逐渐暴露出很多问题。小米网每年有两大促销活动，一个是天猫的双十一活动，另外一个是小米自己的米粉节。这两个节日，小米网的订单量是呈爆发式的增长，而且每年的订单量峰值都会有所增加。这对业务系统，尤其是作为中心节点的Notify系统来说，是一次巨大的冲击。所以Notify消息系统在最初设计的基础经过了很多修改，并且于去年完成了一次大的重构，才达到了现在的处理能力，以目前的性能来看，小米网可以轻松经受住米粉节或双十一的订单量。

目前Notify系统主要的不足有以下几点：

业务直接通过接口方式投递消息。如果网络出现不可靠的情况，直接投递还是会有引起业务失败的风险；

系统全部使用PHP来实现。做为一种脚本语言，PHP还是有很多不足的地方，比如无法进行高效的运算；

采用单一MySQL实例。在数据量过大时会影响性能。

针对上面的这些不足，我们对Notify进行了一些重构。首先，对于接收消息的功能，我们改为采用Agent代理的方式，来收集消息。如图6所示：

图6 Notify采用Agent代理的方式

业务系统由原来的直接将消息发送给Notify，改为将消息存在本地数据库，然后由常驻内存的Agent代理来收集消息，并将消息发送给Notify系统。如此以来，大大增加了业务的成功率，因为DB操作的可靠性远大于网络操作。

对于PHP问题，我们则是采用Golang将关键的模块进行了重构。经过这次重构，主要模块的性能都有了很大的提升。与老版本对比，Api.Notify系统每台Web服务器接收消息的能力提升了21倍，Marker服务处理能力提升了4倍，Sender服务处理能力提升了4倍。最终投递周期中的各环节性能达到了图7中所示：

图7

针对单一MySQL实例问题，我们引入了MyCAT，MyCAT是阿里开发并维护的一款开源数据库中间件，实现了MySQL的分布式存储，提升了数据库性能，并且MySQL实例数量动态可扩展，最重要的是MyCAT可运行MySQL语句，因此与MySQL几乎无缝切换，开发成本小。

总结

本文主要介绍了小米网在实现异步消息队列系统时所进行的实践与探索，介绍了异步消息系统的设计经验，为其他公司的实践提供保贵经验。

最后给大家分享一些资源，转发 关注我，私信回复“架构资料”获取以上资料视频、往期Java高级架构资料、源码、笔记、视频、Dubbo、Redis、Netty、zookeeper、Spring cloud、分布式、高并发等架构技术