蚂蚁上市员工人均一套大 House，阿里程序员身价和这匹配吗？

作者 | 硬核云顶宫

责编 | 伍杏玲

出品 | CSDN（ID:CSDNnews）

上周，蚂蚁集团迎来IPO，其发行价格将达到68.8元，总市值将突破2万亿元。市场对蚂蚁的成长性有着充分的信心，为了申购蚂蚁的股票，10月27日多家券商的交易系统热情的股民们拥挤而产生瘫痪。

据蚂蚁集团招股书信息显示，截至 2020 年 9 月 30 日，经济受益权激励计划项下的经济利益所对应发行人股份合计 30.79 亿股，授予蚂蚁集团的员工及顾问的比例约为 65%。如果以 68.8 元人民币的发行价计算，蚂蚁集团的员工及顾问共计可获得约 1376.9 亿元人民币的经济收益。截止6月30日，蚂蚁员工总计16660人。如果照此计算，蚂蚁集团人均可摊到 826.47 万元人民币。以笔者对于阿里及蚂蚁的了解，其研发人员占比80%以上，这样的激励计划主要惠及程序员群体，看到这样的消息不少码农们纷纷表示羡慕，也有人质疑阿里的程序员到底能否配得上这样的身价。

与阿里云的广为人知的原创技术飞天操作系统和神龙服务器不同，笔者认为蚂蚁对于IT界最大的贡献在于创造一套秒杀系统的技术体系，而目前一个能提供良好客户体验的秒杀系统已经逐渐成为了互联网企业的必备神器了，不过秒杀系统不是一天炼成的，其背后的黑科技值得我们深入探寻。

秒杀系统 IOE 所不能随之重

十几年前随着淘宝和支付宝的诞生，网络购物对于线下零售排队是降维打击，网络时代的“抢购”，再也不用早起排队。在这样的这种场景下，任何毫秒级的延误，都会造成物体验的恶化，如何让用户愉快地剁手，是阿里、腾讯这样的互联网公司必须要解决的问题。

自此，我国互联网企业普遍迎来了第一波流量爆发。淘宝双十一的交易额从2005年的80亿直线升到2012年的破千亿，这种爆炸式增长成了阿里、腾讯“甜蜜”的负担，大家发现其用户的增长速度已超出系统处理能力的提升速度，原有一直沿用的IOE中心化系统与这种高用户并发的场景几乎格格不入，不无说达到如此性能的IOE系统成本会有多惊人，问题的关键在于即使是当时最强大的科技公司IOE，也没有经历过上亿用户同时在线的业务场景。时任阿里CTO的王坚院士率先提出“去IOE”的目标，通过打造阿里自己的技术来解决用户爆发式增长的问题。

“去IOE”是上云的另一种表述方式，在IOE架构的系统中提升算力的思路是让服务器越来越强，云计算的分布式思路是只需要增加服务器节点的数量，就能处理更多的并发服务请求。云系统业务的连续性并不是靠高可用性来保证，而是靠整个服务体系的容错能力造就的。正是在不断探索中，阿里人摸索出了新的云计算分布式架构，通过发挥云计算的威力，使得看似普通的虚拟机集群，能为亿万用户同时提供优质的服务。

秒杀系统技术栈的演进路径

考虑到双十一需要在短时间内处理上亿并发量，即便是世界最强超算可能也力不从心，因此建设这样的系统须进行分布式架构的改造。分布式系统包含多个相连的处理资源，这些资源能在系统的控制下，对单一问题进行合作，最少依赖集中过程、数据或硬件，快速构建应对高并发和复杂业务场景的能力，分布式系统有一个重要的原则CAP定理。

CAP定理：是指在一个分布式系统（Distributed System）中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance），呈不可能三角关系，既三个目标只能同时做到两点，不可能三者兼顾。

CAP定理并不难理解，如果满足一致性、高可用性，那么一旦集群内有节点故障，为保证数据一致，必将使系统整体陷入中断。如果既满足可用性、又满足分区容错性，那么必然存在某个节点在系统对外提供服务时出现宕机，而这时各节点的数据一致性，又无法完全保证。

结合秒杀系统的需求分析，系统可用性肯定是要首先保证的，正如上文所述，当代的消费者无法接受排队等待，如果活动当天页面无法访问，那恐怕营销不成，让用户路转黑了。在大流量的冲击下，可能会发生节点故障。因此分区容错性需要保证，这样看来，能稍微放一放的只有数据一致性，因此从这个角度上讲，交易的总额必然会围绕期望值上下浮动。

双十一秒杀系统，一般会将以哈希分配与平均预分布两种方案结合。首先根据历史经验，将交易量相量的地区结合，分为一组，比如北京、天津和辽宁、长春分为一组、上海、苏州、南京分为二组等等以此类推，与之对应的云集群，都有自己独立的商品额度，也只处理发给自己的请求。这样既能避免入口的瓶颈，也尽量平均分配了请求的处理量。

每个集群也会将额度分配给内部的服务器，然后每个服务器会将自己库存范围内的请求，直接标志为成功，并在自己库存范围的基础上，还会多预留一定比例的需求为待定，待统一减库存后再确定能否待请求能否成功。

从分布式的角度来看，分区域与分库存是系统设计的基础环节，而接下来要做的就是解决分布式一致性的问题了，只要分布式一致性的问题解决了，那么无论会么形式的抢购都可以迎刃而解。

分布式事务一致性，“秒杀系统”的核心

秒杀系统对技术要求非常高，其中最关键的钥匙，在于解决分布式事务一致性的难题。无论是购买余额宝、信用卡还款还是相互保，都是典型的分布式场景，在分布式场景下银行、基金、保险与支付宝对于一笔交易的记录必须同时成功，或者同时失败，以保证事务的原子性。

一般来讲解决事务一致性问题，有两种解决方案：

一是类似于阿里的Oceanbase分布式数据库所使用的方式，他们将事务分为Prepare和Commit两个阶段来进行提交：

1.请求发起：首先由应用程序（client）发起一个事务开始请求到TC（事务协调器）；

2.TC发起prepare流程：TC先将prepare消息写到本地日志，之后向所有的Si发起prepare消息。还是以以支付宝向信用卡还款为例，TC给A的prepare消息是通知支付宝数据库相应账目扣款1千，TC给B的prepare消息是通知余额宝数据库相应账目增加1千。为什么在执行任务前需要先写本地日志，主要是为了故障后恢复用，本地日志起到现实生活中凭证的效果，如果没有本地日志（凭证），出问题容易死无对证；

3.节点处理prepare流程：在各分布式节点收到prepare消息后，执行具体本机事务，但不会进行commit，如果成功返回yes，不成功返回no。同理，返回前都应把要返回的消息写到日志里，当作凭证。

4.流程投票：TC收集所有节点返回的消息，如果所有执行器都返回yes，那么给所有执行器发生送commit消息，执行器收到commit后执行本地事务的commit操作；如果有任一个执行器返回no，那么给所有执行器发送abort消息，执行器收到abort消息后执行事务abort操作。

以支付宝信用卡还款操作以下“银行处理中”界面恰恰从侧面印证了这个信息同步的过程。

而分布式事务一致性就是要保证不同的两个节点间信息是完全同步的，带有“**处理中”字样的交易往往是非实时性的交易。这说明要保证分布式事务一致性的系统，其付出的时间同步成本一般也会是比较高昂的。

这方面OceanBase的使用策略是通过Paxos分布式协议在各节点中进行投票的，在性能优化方面Oceanbase在今年6月再次刷榜拿下TPC冠军的OcceanBase，处理峰值也达到7亿次/秒，将自己去年创造的6100万次/秒，提高了11倍。

另一种是基于事务型消息队列来保证分布式一致性的：目前在主流的消息队列产品中，RabbitMQ和Kafka都是不支持事务消息的，目前只有阿里研发并开源的RocketMQ支持事务功能，其事务消息功能既保证操作DB操作双方的最终一致性；并且在consumer端支持tag过滤，减少不必要的网络传输。

未来各行各业若要保证良好的客户体验，又要从容面对随时可能到来的流量高峰，就必须仿照微博、淘宝的方式将核心系统全面迁移到分布式数据库上去，这样才能使自身服务体系保持足够的弹性，迅速响应各种营销热点。如果不对核心换代升级，继续死守传统的物理架构，不论存在技术断供的风险，单从业务发展来说，未来的空间将十分狭小。

在这方面，阿里云正在将蚂蚁乃至整个阿里的服务能力SaaS化，他们提供覆盖底层基础架构一直到上层应用开发的全链路分布式技术产品和轻型解决方案，通过异地多活、单元化、微服务、中台等创新技术改造，秒杀类核心系统安全、高效和稳定地应对未来业务场景。

更多精彩推荐

点分享点点赞点在看