我所经历的“余额宝”的那些故事

　　此时已进入到2002年7月中旬。根据对一期系统运行状态趋势的评估，一期系统的容量在没有任何运营推广运动的情形下，只能支持到9月份便碰面临瓶颈。在理清晰二期系统的性能和容量设计目的时，樊振华又接到了新的压力：天弘基金和支付宝治理层已决议余额宝要到场阿里“双十一”购物狂欢节，这对于支持后台的手艺职员来讲，绝对是一场恶战。很快，传来了支付宝对天弘提出的双十一支持要求：

实时请求的响应要凌驾1000笔每秒；整理系统要支持单日3亿笔生意业务整理，整理时间不得凌驾150分钟；2002年10月份支付宝会睁开相关运营运动，系统必须在10月份前上线。

　　面临这样严酷的要求，且只有两个月的系统革新时间，项目组遇到了庞大的难题。

　　1. 怎样举行系统水平拆分？

　　根据“蚁群战术”，需要将原有系统的营业逻辑水平拆分成多组小系统。而怎样才气保证拆分尽可能平均和拆分后的扩展性是绕不外去的难点。水平拆分依据哪个字段来拆分，需要凭据营业特征稳重思量。一个细节思量不到会导致通盘皆输。

　　2. 将Oracle替换为MySQL。

　　无论是单机性能照旧功效，MySQL都无法与单机的Oracle匹敌。使用My沈阳小程序设计SQL取代Oracle，原有的存储历程该怎么办呢？一些涉及多表join的操作在MySQL下执行效率较低该怎样解决？事情量有多大？没人清晰这一系列问题的谜底。

　　3. 数据迁徙工程浩荡，难度极高。

　　一期系统部署在天弘基金在天津的数据中央，而二期系统却部署在阿里云在沈阳的节点，怎样做到无缝割接？而且思量到互联网用户的用户体验，一期系统和二期系统在上线时代，不允许泛起营业中止，项目组必须在大数据量、异构情况、远程迁徙等庞大情况下，实现无缝迁徙。做到上线历程最终客户无感知。

　　4. 直销和TA系统的资源争抢问题。

　　一期方案将直销和TA举行了融合，来解决数据交互问题。但由于传统的TA与实时请求在差别时段运行，以是接纳了自动争抢机制的负载平衡及贪心式的CPU占用，以保证充实使用硬件资源完成营业整理。这在传统模式下没有问题，但一期系统举行合并以后，TA和实时请求的应用系统部署在统一组服务器上，每次TA系统汇海整理的时间段，会严重影响实时请求的响应时间，甚至造成响应失败。

　　5. 整个架构保持两年以上系统扩容能力。

　　上云后的系统必须能够知足营业量飞速高涨的情形下，可以凭据营业量的巨细做到无缝升级。两年之内，不能由于扩容而改变系统架构。在保证扩容性的条件下，经济和投入必须控制在合理规模内。

　　这些问题，不管是樊振华，照旧金证科技，在漫衍式系统和云盘算这个领域，虽然相识许多，但真正动刀枪，照旧第一次。纵然阿里云和支付宝的手艺职员，在这么短的时间内，要解决这么多灾题，也都不禁捏一把汗。

　　走投无路，背水一战

　　樊振华清晰自己已没有退路，只有往前走才是出路。他召集阿里云、天弘基金、金证科技和支付宝的手艺职员在闭关室举行关闭式开发，一场艰辛的战争就此打响。

　　“管不了那么多，这些问题只能一个一个解决。”樊振华每次面临棘手的难题时总会说这么一句。最终难题都被解决了。

　　1. 系统水平拆分。系统水平拆分的基本原理很简朴，就是按一个营业字段，如支付宝协议号作为拆分依据。对字段取哈希值以后凭据拆分虚节点的个数举行求模。这样就可以简朴地将所有请求拆分成多份。

　　在二期系统的拆分历程中，经由测算，需要使用50组营业节点，但在拆分时，思量到扩展性，并未简朴地拆分成50份，而是拆分成1000份，然后每个节点处置惩罚20份数据。这样做的利益是未来若是系统遇到瓶颈，需要扩容时，不需要对拆分算法举行修改，而且数据平均迁徙时只需要以库为级别举行，从而制止了拆表。

　　2. 去Oracle。首先是将存储历程等MySQL不支持或支持欠好的数据库逻辑上移到应用中。

　　其次要将庞大度比力高的SQL语句举行拆分，酿成多条简朴的SQL语句，从而提高MySQL的执行效率。

　　阿里云的RDS提供的慢SQL查询功效，可以将整个系统执行效率比力慢的SQL出现给用户，资助用户优化SQL语句。

　　3. 数据迁徙。数据迁徙是这个项目的重头戏，迁徙历程中使用全量+增量+数据校勘+并行运行检查等几个阶段完成。

 3/4   首页 上一页 1 2 3 4 下一页 尾页