本文原题“阿里数据库十年变迁，那些你不知道的二三事”，来自阿里巴巴官方技术公号的分享。
1、引言
第十个双11即将来临之际，阿里技术推出《十年牧码记》系列，邀请参与历年双11备战的核心技术大牛，一起回顾阿里技术的变迁。
今天，阿里数据库事业部研究员张瑞，将为你讲述双11数据库技术不为人知的故事。在零点交易数字一次次提升的背后，既是数据库技术的一次次突破，也见证了阿里技术人永不言败的精神，每一次化“不可能”为“可能”的过程都是阿里技术人对技术的不懈追求。
（本文同步发布于：http://www.52im.net/thread-2050-1-1.html）
2、分享者
张瑞：阿里集团数据库技术团队负责人，阿里巴巴研究员，Oracle ACE。双十一数据库技术总负责人，曾两次担任双十一技术保障总负责人。自2005年加入阿里巴巴以来，一直主导整个阿里数据库技术的不断革新。
3、阿里数据库技术发展回顾
再过几天，我们即将迎来第十个双11。过去十年，阿里巴巴技术体系的角色发生了转变，从双11推动技术的发展，变成了技术创造新商业。很多技术通过云计算开始对外输出，变成了普惠的技术，服务于各个行业，真正做到了推动社会生产力的发展。
这十年，阿里巴巴数据库团队一直有一个使命：推动中国数据库技术变革。从商业数据库到开源数据库再到自研数据库，我们一直在为这个使命而努力奋斗。
如果将阿里数据库发展历史分为三个阶段的话，分别是：
第一阶段（2005-2009）商业数据库时代；
第二阶段（2010-2015）开源数据库时代；
第三阶段（2016年-至今）自研数据库时代。
商业数据库时代就是大家所熟知的IOE时代，后来发生了一件大事就是“去IOE”：通过分布式数据库中间件TDDL、开源数据库AliSQL（阿里巴巴的MySQL分支）、高性能X86服务器和SSD，并通过DBA和业务开发同学的共同努力，成功地替换了商业数据库Oracle、IBM小型机和EMC高端存储，从此进入了开源数据库时代。
去IOE带来了三个重大的意义：
第一：是解决了扩展性的问题，让数据库具备了横向扩展（弹性）的能力，为未来很多年双11零点交易峰值打下了很好的基础。
第二：是自主可控，我们在AliSQL中加入了大量的特性，比如：库存热点补丁，SQL限流保护，线程池等等，很多特性都是来源于双11对于数据库的技术要求，这在商业数据库时代是完全不可能的。
第三：是稳定性，原来在商业数据库时代，就如同把所有的鸡蛋放在一个篮子里（小型机），去IOE之后不仅仅解决了单机故障，更是通过异地多活的架构升级让数据库跨出了城市的限制，可以实现数据库城市间的多活和容灾，大大提升了系统的可用性。
小知识：什么是“去IOE”？
“去IOE”它是阿里巴巴造出的概念。其本意是，在阿里巴巴的IT架构中，去掉IBM的小型机、Oracle数据库、EMC存储设备，代之以自己在开源软件基础上开发的系统。
自2013年棱镜门事件之后，我国政府已经意识到政府数据安全的重要性，也加强了政府数据安全方面的工作，有报道称，思科、IBM、谷歌、高通、英特尔、苹果、甲骨文、微软并称为美国的“八大金刚”，他们一方面与美国政府、军队保持着紧密的联系；另一方面在中国长驱直入，占据众多关键领域，导致美国情报部门通过这些设备、软件、网络获取信息，给中国的信息安全带来巨大威胁。“去IOE”与设备采购国产化、自主研发等口号挂钩，带有一定的政治色彩。
2008年阿里提出去IOE时不少人觉得是痴人说梦，但经过多年运营阿里云已经彻底完成了去IOE工作，即阿里云的硬件投入彻底抛弃了这三家传统企业，经历几次双十一的挑战之后该技术也趋于成熟，有媒体猜测这或许是12306选择阿里云的重要原因。
进入2016年，我们开始自研数据库，代号X-DB。
大家一定会问：为什么要自研数据库？有以下几个原因：
【第一】：我们需要一个能够全球部署的原生分布式数据库，类似于Google Spanner。
【第二】：是双11的场景对数据库提出了极高的要求：
性能：在双11零点需要数据库提供非常高的读写能力；
存储成本：数据库使用SSD来存储数据，而数据存在明显的冷热特性，大量冷的历史数据和热的在线数据存放在一起，日积月累，占用了大量宝贵的存储空间，存储成本的压力越来越大。
我们经过认真评估后发现，如果继续在开源数据库基础上进行改进已经无法满足业务需求。
【第三】：是新的硬件技术的出现，如果说SSD的大规模使用和X86服务器性能的极大提升推动了去IOE的进程，那么NVM非易失内存，FPGA异构计算，RDMA高速网络等技术将第二次推动数据库技术的变革。
伴随着每一年的双11备战工作，机器资源的准备都是非常重要的一个环节。如何降低双11的机器资源成本一直是阿里技术人不断挑战自我的一个难题。
第一个解决方案就是使用云资源，数据库从2016年初开始就尝试使用高性能ECS来解决双11的机器资源问题。通过这几年的双11的不断磨练，2018年双11，我们可以直接使用了公有云ECS，并通过VPC网络与阿里巴巴集团内部环境组成混合云，实现了双11的弹性大促。
第二个方案就是在线离线混部，日常让离线任务跑在在线（应用和数据库）的服务器上，双11大促在线应用使用离线的计算资源，要实现这种弹性能力，数据库最核心要解决一个技术问题就是：存储计算分离。存储计算分离后，数据库可以在双11使用离线的计算资源，从而实现极致的弹性能力。通过使用云资源和混部技术，可以最大程度降低双11交易峰值带来的成本。
双11备战中另外一个重要的技术趋势就是：智能化。数据库和智能化相结合也是我们一直在探索的一个方向，比如Self-driving Database等。2017年，我们第一次使用智能化的技术对SQL进行自动优化，2018年，我们计划全网推广SQL自动优化和空间自动优化，希望可以使用这些技术降低DBA的工作负担，提升开发人员效率，并有效提升稳定性。相信未来，在双11的备战工作中，会有越来越多的工作可以交给机器来完成。
我从2012年开始参加双11的备战工作，多次作为数据库的队长和技术保障部总队长，在这么多年的备战工作中，我也经历了很多有意思的故事，在这里分享一些给大家。
4、2012年：我的第一次双11
2012年是我的第一次双11，在此之前，我在B2B的数据库团队，2012年初，整个集团的基础设施团队都合并到了技术保障部，由振飞带领。我之前从来没有参加过双11，第一年参加双11后羿（数据库团队的负责人）就把队长的职责给了我，压力可想而知。那时候备战双11的工作非常长，大概从5、6月份就开始准备了，最重要的工作就是识别风险，并准确评估出每个数据库的压力。
我们需要把入口的流量转换为每个业务系统的压力QPS，然后我们根据业务系统的QPS转换为数据库的QPS，2012年还没有全链路压测的技术，只能靠每个业务系统的线下测试，以及每个专业线队长一次又一次的开会review来发现潜在的风险。
可想而知，这里面存在巨大的不确定性，每个人都不想自己负责的业务成为短板，而机器资源往往是有限的，这时，就完全靠队长的经验了，所以，每个队长所承担的压力都非常巨大。我记得当年双11的大队长是李津，据说他当时的压力大到无法入睡，只能在晚上开车去龙井山顶，打开车窗才能小憩一会。
而我，由于是第一年参加双11，经验为零，完全处于焦虑到死的状态，幸好当年有一群很靠谱兄弟和我在一起，他们刚刚经历了去IOE的洗礼，并且长期与业务开发浸淫在一起，对业务架构和数据库性能如数家珍，了若指掌。通过他们的帮助，我基本摸清了交易整套系统的架构，这对我未来的工作帮助非常大。
经过几个月紧张的准备，双11那天终于到来了，我们做好了最充分的准备，但是一切都是那么地不确定，我们怀着忐忑不安的心情，当零点到来的时候，最坏的情况还是发生了：库存数据库的压力完全超过了容量，同时IC（商品）数据库的网卡也被打满了。我记得很清楚，当时我们看着数据库的上的监控指标，束手无策。这里有一个小细节：由于我们根本没有估算到这么大的压力，当时监控屏幕上数据库的压力指标显示超过了100%。
正在这时，技术总指挥李津大喊一声：“大家都别慌！”这时我们才抬头看到交易的数字不断冲上新高，心里才稍微平静下来。事实上，对于IC数据库网卡被打满，库存数据库超过容量，都超出了我们的预期，所以最终我们什么预案也没做，就这样度过了零点的高峰。
因为这些原因，2012年的的双11产生了大量的超卖，给公司带来了很大的损失。那一年的双11后，库存、商品、退款和相应数据库的同学，为了处理超卖导致的问题，没日没夜加了两周的班。而且，我周围很多朋友，都在抱怨高峰时的用户体验实在太糟糕了。我们下决心要在第二年的双11解决这些问题。
5、2013年：库存热点优化和不起眼的影子表
2012年的双11结束后，我们就开始着手解决库存数据库的性能提升。库存扣减场景是一个典型的热点问题，即多个用户去争抢扣减同一个商品的库存（对数据库来说，一个商品的库存就是数据库内的一行记录），数据库内对同一行的更新由行锁来控制并发。我们发现当单线程（排队）去更新一行记录时，性能非常高，但是当非常多的线程去并发更新一行记录时，整个数据库的性能会跌到惨不忍睹，趋近于零。
当时数据库内核团队做了两个不同的技术实现：一个是排队方案，另一个并发控制方案。两者各有优劣，解决的思路都是要把无序的争抢变为有序的排队，从而提升热点库存扣减的性能问题。两个技术方案通过不断的完善和PK，最终都做到了成熟稳定，满足业务的性能要求，最终为了万无一失，我们把两个方案都集成到了AliSQL（阿里巴巴的MySQL分支）中，并且可以通过开关控制。最终，我们通过一整年的努力，在2013年的双11解决了库存热点的问题，这是第一次库存的性能提升。在这之后的2016年双11，我们又做了一次重大的优化，把库存扣减性能在2013年的基础上又提升了十倍，称为第二次库存性能优化。
2013年堪称双11历史上里程碑式的一年，因为这一年出现了一个突破性的技术-全链路压测。我非常佩服第一次提出全链路压测理念的人-李津，他当时问我们：有没有可能在线上环境进行全仿真的测试？所有人的回答都是：不可能！当然，我认为这对于数据库是更加不可能的，最大的担心是压测流量产生的数据该如何处理，从来没听说过哪家公司敢在线上系统做压测，万一数据出现问题，这个后果将会非常严重。
我记得在2013年某天一个炎热的下午，我正在库存数据库的问题中焦头烂额的时候，叔同(全链路压测技术负责人)来找我商量全链路压测数据库的技术方案。就在那个下午，我们两个人讨论出了一个“影子表”的方案，即在线上系统中建立一套“影子表”来存储和处理所有的压测数据，并且由系统保证两套表结构的同步。但是，我们对这件事心里都没底，我相信在双11的前几周，没有几个人相信全链路压测能够落地，我们大部分的准备工作还是按照人工review+线下压测的方式进行。但是，经过所有人的努力，这件事竟然在双11前两周取得了突破性进展，当第一次全链路压测成功的时候，所有人都觉得不敢相信。
最后，双11的前几个晚上，几乎每天晚上都会做一轮全链路压测，每个人都乐此不疲，给我留下的印象实在太深刻了。但这个过程，也并不是一帆风顺，我们压出了很多次故障，多次写错了数据，甚至影响了第二天的报表，长时间高压力的压测甚至影响了机器和SSD的寿命。即便出现了如此多的问题，大家依然坚定地往前走，我觉得这就是阿里巴巴与众不同的地方，因为我们相信所以看见。事实也证明，全链路压测变成了双11备战中最有效的大杀器。
如今，全链路压测技术已经成为阿里云上的一个产品，变成了更加普惠的技术服务更多企业。
6、2015年：大屏背后的故事
2015年，我从数据库的队长成为整个技术保障部的总队长，负责整个技术设施领域的双11备战工作，包括IDC、网络、硬件、数据库、CDN，应用等所有技术领域，我第一次面对如此多的专业技术领域，对我又是一次全新的挑战。但是，这一次我却被一个新问题难倒了：大屏。
2015年，我们第一次举办天猫双11晚会，这一年晚会和媒体中心第一次不在杭州园区，而是选择在北京水立方，媒体中心全球26小时直播，全球都在关注我们双11当天的盛况，需要北京杭州两地协同作战，困难和挑战可想而知！
大家都知道对媒体直播大屏来说最最重要的两个时刻，一个是双11零点开始的时刻，一个是双11二十四点结束的时刻，全程要求媒体直播大屏上跳动的GMV数字尽可能的不延迟，那一年我们为了提升北京水立方现场的体验及和杭州总指挥中心的互动，在零点前有一个倒计时环节，连线杭州光明顶作战指挥室，逍遥子会为大家揭幕2015双11启动，然后直接切换到我们的媒体大屏，所以对GMV数字的要求基本上是零延迟，这个挑战有多大不言而喻！
然而，第一次全链路压测时却非常不尽人意，延时在几十秒以上，当时的总指挥振飞坚决的说：GMV第一个数字跳动必须要在5秒内，既要求5秒内就拿到实时的交易数字，又要求这个数字必须是准确的，所有人都觉得这是不可能完成的任务。
当时，导演组也提了另外一个预案，可以在双11零点后，先显示一个数字跳动的特效（不是真实的数字），等我们准备好之后，再切换到真实的交易数字，但对媒体大屏来说所有屏上的数据都必须是真实且正确的（这是阿里人的价值观），所以我们不可能用这个兜底的方案，所有人想的都是如何把延迟做到5秒内，当天晚上，所有相关的团队就成立一个大屏技术攻关组，开始封闭技术攻关，别看一个小小的数字，背后涉及应用和数据库日志的实时计算、存储和展示等全链路所有环节，是真正的跨团队技术攻关，最终不负众望，我们双11零点GMV第一个数字跳动是在3秒，严格控制在5秒内，是非常非常不容易的！不仅如此，为了保证整个大屏展示万无一失，我们做了双链路冗余，类似于飞机双发动机，两条链路同时计算，并可实时切换。
我想大家一定不了解大屏上一个小小的数字，背后还有如此多的故事和技术挑战吧。双11就是如此，由无数小的环节组成，背后凝聚了每个阿里人的付出。
7、2016年：吃自己的狗粮
做过大规模系统的人都知道，监控系统就如同我们的眼睛一样，如果没有它，系统发生什么状况我们都不知道。我们数据库也有一套监控系统，通过部署在主机上的agent，定期采集主机和数据库的关键指标，包括：CPU和IO利用率，数据库QPS、TPS和响应时间，慢SQL日志等等，并把这些指标存储在数据库中，进行分析和展示，最初这个数据库也是MySQL。
随着阿里巴巴数据库规模越来越大，整个监控系统就成为了瓶颈，比如：采集精度，受限于系统能力，最初我们只能做到1分钟，后来经过历年的优化，我们把采集精度提升到10秒。但是，最让人感到尴尬的是：每一年双11零点前，我们通常都有一个预案：对监控系统进行降级操作，比如降低采集精度，关闭某些监控项等等。这是因为高峰期的压力太大，不得已而为之。
另外一个业务挑战来自安全部，他们对我们提出一个要求，希望能够采集到每一条在数据库上运行的SQL，并能实时送到大数据计算平台进行分析。这个要求对我们更是不可能完成的任务，因为每一个时刻运行的SQL是非常巨大的，通常的做法只能做到采样，现在要求是一条不漏的记录下来，并且能够进行分析，挑战非常大。
2016年双11，我们启动了一个项目：对我们整个监控系统进行了重新设计。目标：具备秒级监控能力和全量SQL的采集计算能力，且双11峰值不降级。第一是要解决海量监控数据的存储和计算问题，我们选择了阿里巴巴自研的时序数据库TSDB，它是专门针对IOT和APM等场景下的海量时序数据而设计的数据库。第二是要解决全量SQL的采集和计算的问题，我们在AliSQL内置了一个实时SQL采集接口，SQL执行后不需要写日志就直接通过消息队列传输到流计算平台上进行实时处理，实现了全量SQL的分析与处理。解决了这两个技术难题后，2016年双11，我们达到了秒级监控和全量SQL采集的业务目标。
后来，这些监控数据和全量SQL成为了一个巨大的待挖掘的宝库，通过对这些数据的分析，并与AI技术相结合，我们推出了CloudDBA数据库智能化诊断引擎。我们相信数据库的未来是Self-drvingdatabase，它有四个特性：自诊断、自优化、自决策和自恢复。如前文所述，目前我们在智能化方向上已经取得了一些进展。
现在，TSDB已经是阿里云上的一个产品，而CloudDBA除了服务阿里巴巴内部数万工程师，也已经在云上为用户提供数据库优化服务。我们不仅吃自己的狗粮，解决自己的问题，同时也用阿里巴巴的场景不断磨练技术，服务更多的云上用户。这就是双11对技术的推动作用。
8、2016-2017：数据库和缓存那点儿事
在双11的历史上，阿里巴巴自研缓存-Tair是非常重要的技术产品，数据库正是因为有了Tair的帮助，才扛起了双11如此巨大的数据访问量。
在大规模使用Tair的同时，开发同学也希望数据库可以提供高性能的KV接口，并且通过KV和SQL两个接口查询的数据是一致的，这样可以大大简化业务开发的工作量，X-KV因此因用而生，它是X-DB的KV组件，通过绕过SQL解析的过程，直接访问内存中的数据，可以实现非常高的性能以及比SQL接口低数倍的响应时间。
X-KV技术在2016年双11第一次得到了应用，用户反馈非常好，QPS可以做到数十万级别。在2017年双11，我们又做了一个黑科技，通过中间件TDDL自动来实现SQL和KV的转换，开发不再需要同时开发两套接口，只需要用SQL访问数据库，TDDL会自动在后台把SQL自动转换为KV接口，进一步提升了开发的效率，降低了数据库的负载。
2016年双11，Tair碰到了一个业界技术难题：热点。
大家都知道缓存系统中一个key永远只能分布在一台机器上，但是双11时，热点非常集中，加上访问量非常大，很容易就超出了单机的容量限制，CPU和网卡都会成为瓶颈。由于热点无法预测，可能是流量热点，也可能是频率热点，造成2016年双11我们就像消防队员一样四处灭火，疲于奔命。
2017年，Tair团队的同学就在思考如何解决这个业界的技术难题，并且创新性地提出了一种自适应热点的技术方案：
第一是智能识别技术： Tair内部采用多级LRU的数据结构，通过将访问数据Key的频率和大小设定不同权值，从而放到不同层级的LRU上，这样淘汰时可以确保权值高的那批Key得到保留。最终保留下来且超过阈值设定的就会判断为热点Key；
第二是动态散列技术：当发现热点后，应用服务器和Tair服务端就会联动起来，根据预先设定好的访问模型，将热点数据动态散列到Tair服务端其它数据节点的HotZone存储区域去访问。
热点散列技术在2017年双11中取得了非常显著的效果，通过将热点散列到整个集群，所有集群的水位均降低到了安全线下。如果没有这个能力，那么2017年双11很多Tair集群都可能出现问题。
可以看出，数据库和缓存是一对互相依赖的好伙伴，他们互相借鉴，取长补短，共同撑起了双11海量数据存储和访问的一片天。
9、2016-2017年：如丝般顺滑的交易曲线是如何做到的
自从有了全链路压测这项技术后，我们希望每一年双11零点的交易曲线都能如丝般顺滑，但是事情往往不像预期的那样顺利。2016年双11零点后，交易曲线出现了一些波动，才攀逐步升到最高点。事后复盘时，我们发现主要的问题是购物车等数据库在零点的一刹那，由于Buffer pool中的数据是“冷”的，当大量请求在零点一瞬间到来时，数据库需要先“热”起来，需要把数据从SSD读取到Buffer pool中，这就导致瞬间大量请求的响应时间变长，影响了用户的体验。
知道了问题原因后，2017年我们提出了“预热””技术，即在双11前，让各个系统充分“热”起来，包括Tair，数据库，应用等等。为此专门研发了一套预热系统，预热分为数据预热和应用预热两大部分，数据预热包括：数据库和缓存预热，预热系统会模拟应用的访问，通过这种访问将数据加载到缓存和数据库中，保证缓存和数据库BP的命中率。应用预热包括：预建连接和JIT预热，我们会在双11零点前预先建立好数据库连接，防止在高峰时建立连接的开销。同时，因为业务非常复杂，而JAVA代码是解释执行的，如果在高峰时同时做JIT编译，会消耗了大量的CPU，系统响应时间会拉长，通过JIT预热，保证代码可以提前充分编译。
2017年双11，因为系统有了充分的预热，交易曲线在零点时划出了一道完美的曲线。
10、2017-2018年：存储计算分离的技术突破
2017年初，集团高年级技术同学们发起了一个技术讨论：到底要不要做存储计算分离？由此引发了一场扩日持久的大讨论。包括我在王博士的班上课时，针对这个问题也进行了一次技术辩论，由于两方观点势均力敌，最终谁也没有说服谁。对于数据库来说，存储计算分离更加是一个非常敏感的技术话题，大家都知道在IOE时代，小型机和存储之间通过SAN网络连接，本质上就是属于存储计算分离架构。现在我们又要回到这个架构上，是不是技术的倒退？另外，对于数据库来说，IO的响应延时直接影响了数据库的性能，如何解决网络延时的问题？各种各样的问题一直困扰着我们，没有任何结论。
当时，数据库已经可以使用云ECS资源来进行大促弹性扩容，并且已经实现了容器化部署。但是，我们无论如何也无法回避的一个问题就是：如果计算和存储绑定在一起，就无法实现极致的弹性，因为计算节点的迁移必须“搬迁”数据。而且，我们研究了计算和存储的能力的增长曲线，我们发现在双11高峰时，对于计算能力的要求陡增，但是对于存储能力的要求并没有发生显著变化，如果可以实现存储计算分离，双11高峰我们只需要扩容计算节点就可以了。综上所述，存储计算分离是华山一条路，必须搞定。
2017年中，为了验证可行性，我们选择在开源分布式存储Ceph的基础上进行优化，与此同时，阿里巴巴自研高性能分布式存储盘古2.0也在紧锣密鼓的开发中。另外一方面，数据库内核团队也参与其中，通过数据库内核优化减少网络延迟对数据库性能的影响。经过大家的共同努力，最终基于盘古2.0的计算存储分离方案都在2017年双11落地，并且验证了使用离线机头挂载共享存储的弹性方案。经过这次双11，我们证明了数据库存储计算分离是完全可行的。
存储计算分离的成功离不开一位幕后英雄：高性能和低延迟网络，2017年双11我们使用了25G的TCP网络，为了进一步降低延迟，2018年双11我们大规模使用了RDMA技术，大幅度降低了网络延迟，这么大规模的RDMA应用在整个业界都是独一无二的。为了降低IO延迟，我们在文件系统这个环节也做了一个大杀器-DBFS，通过用户态技术，旁路kernel，实现I/O路径的Zero copy。通过这些技术的应用，达到了接近于本存储地的延时和吞吐。
2018年双11，随着存储计算分离技术的大规模使用，标志着数据库进入了一个新的时代。
11、本文小结
在2012年到2018年的这六年，我见证了零点交易数字的一次次提升，见证了背后数据库技术的一次次突破，更见证了阿里人那种永不言败的精神，每一次化“不可能”为“可能”的过程都是阿里技术人对技术的不懈追求。
感恩十年双11，期待下一个十年更美好。
附录1：大型架构方面的技术文章
《浅谈IM系统的架构设计》
《简述移动端IM开发的那些坑：架构设计、通信协议和客户端》
《一套海量在线用户的移动端IM架构设计实践分享(含详细图文)》
《一套原创分布式即时通讯(IM)系统理论架构方案》
《从零到卓越：京东客服即时通讯系统的技术架构演进历程》
《蘑菇街即时通讯/IM服务器开发之架构选择》
《腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT》
《微信后台基于时间序的海量数据冷热分级架构设计实践》
《微信技术总监谈架构：微信之道——大道至简(演讲全文)》
《如何解读《微信技术总监谈架构：微信之道——大道至简》》
《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》
《17年的实践：腾讯海量产品的技术方法论》
《移动端IM中大规模群消息的推送如何保证效率、实时性？》
《现代IM系统中聊天消息的同步和存储方案探讨》
《IM开发基础知识补课(二)：如何设计大量图片文件的服务端存储架构？》
《IM开发基础知识补课(三)：快速理解服务端数据库读写分离原理及实践建议》
《IM开发基础知识补课(四)：正确理解HTTP短连接中的Cookie、Session和Token》
《WhatsApp技术实践分享：32人工程团队创造的技术神话》
《微信朋友圈千亿访问量背后的技术挑战和实践总结》
《王者荣耀2亿用户量的背后：产品定位、技术架构、网络方案等》
《IM系统的MQ消息中间件选型：Kafka还是RabbitMQ？》
《腾讯资深架构师干货总结：一文读懂大型分布式系统设计的方方面面》
《以微博类应用场景为例，总结海量社交系统的架构设计步骤》
《快速理解高性能HTTP服务端的负载均衡技术原理》
《子弹短信光鲜的背后：网易云信首席架构师分享亿级IM平台的技术实践》
《知乎技术分享：从单机到2000万QPS并发的Redis高性能缓存实践之路》
《IM开发基础知识补课(五)：通俗易懂，正确理解并用好MQ消息队列》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（容灾方案篇）》
《新手入门：零基础理解大型分布式架构的演进历史、技术原理、最佳实践》
《一套高可用、易伸缩、高并发的IM群聊架构方案设计实践》
《阿里技术分享：深度揭秘阿里数据库技术方案的10年变迁史》
>> 更多同类文章 ……
附录2：大厂技术分享
《微信朋友圈千亿访问量背后的技术挑战和实践总结》
《腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)》
《腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(音视频技术篇)》
《微信团队分享：微信移动端的全文检索多音字问题解决方案》
《腾讯技术分享：Android版手机QQ的缓存监控与优化实践》
《微信团队分享：iOS版微信的高性能通用key-value组件技术实践》
《微信团队分享：iOS版微信是如何防止特殊字符导致的炸群、APP崩溃的？》
《腾讯技术分享：Android手Q的线程死锁监控系统技术实践》
《微信团队原创分享：iOS版微信的内存监控系统技术实践》
《让互联网更快：新一代QUIC协议在腾讯的技术实践分享》
《iOS后台唤醒实战：微信收款到账语音提醒技术总结》
《腾讯技术分享：社交网络图片的带宽压缩技术演进之路》
《微信团队分享：视频图像的超分辨率技术原理和应用场景》
《微信团队分享：微信每日亿次实时音视频聊天背后的技术解密》
《QQ音乐团队分享：Android中的图片压缩技术详解（上篇）》
《QQ音乐团队分享：Android中的图片压缩技术详解（下篇）》
《腾讯团队分享：手机QQ中的人脸识别酷炫动画效果实现详解》
《腾讯团队分享 ：一次手Q聊天界面中图片显示bug的追踪过程分享》
《微信团队分享：微信Android版小视频编码填过的那些坑》
《微信手机端的本地数据全文检索优化之路》
《企业微信客户端中组织架构数据的同步更新方案优化实战》
《微信团队披露：微信界面卡死超级bug“15。。。。”的来龙去脉》
《QQ 18年：解密8亿月活的QQ后台服务接口隔离技术》
《月活8.89亿的超级IM微信是如何进行Android端兼容测试的》
《以手机QQ为例探讨移动端IM中的“轻应用”》
《一篇文章get微信开源移动端数据库组件WCDB的一切！》
《微信客户端团队负责人技术访谈：如何着手客户端性能监控和优化》
《微信后台基于时间序的海量数据冷热分级架构设计实践》
《微信团队原创分享：Android版微信的臃肿之困与模块化实践之路》
《微信后台团队：微信后台异步消息队列的优化升级实践分享》
《微信团队原创分享：微信客户端SQLite数据库损坏修复实践》
《腾讯原创分享(一)：如何大幅提升移动网络下手机QQ的图片传输速度和成功率》
《腾讯原创分享(二)：如何大幅压缩移动网络下APP的流量消耗（下篇）》
《腾讯原创分享(三)：如何大幅压缩移动网络下APP的流量消耗（上篇）》
《微信Mars：微信内部正在使用的网络层封装库，即将开源》
《如约而至：微信自用的移动端IM网络层跨平台组件库Mars已正式开源》
《开源libco库：单机千万连接、支撑微信8亿用户的后台框架基石 [源码下载]》
《微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解》
《微信团队原创分享：Android版微信后台保活实战分享(进程保活篇)》
《微信团队原创分享：Android版微信后台保活实战分享(网络保活篇)》
《Android版微信从300KB到30MB的技术演进(PPT讲稿) [附件下载]》
《微信团队原创分享：Android版微信从300KB到30MB的技术演进》
《微信技术总监谈架构：微信之道——大道至简(演讲全文)》
《微信技术总监谈架构：微信之道——大道至简(PPT讲稿) [附件下载]》
《如何解读《微信技术总监谈架构：微信之道——大道至简》》
《微信海量用户背后的后台系统存储架构(视频+PPT) [附件下载]》
《微信异步化改造实践：8亿月活、单机千万连接背后的后台解决方案》
《微信朋友圈海量技术之道PPT [附件下载]》
《微信对网络影响的技术试验及分析（论文全文）》
《一份微信后台技术架构的总结性笔记》
《架构之道：3个程序员成就微信朋友圈日均10亿发布量[有视频]》
《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》
《快速裂变：见证微信强大后台架构从0到1的演进历程（二）》
《微信团队原创分享：Android内存泄漏监控和优化技巧总结》
《全面总结iOS版微信升级iOS9遇到的各种“坑”》
《微信团队原创资源混淆工具：让你的APK立减1M》
《微信团队原创Android资源混淆工具：AndResGuard [有源码]》
《Android版微信安装包“减肥”实战记录》
《iOS版微信安装包“减肥”实战记录》
《移动端IM实践：iOS版微信界面卡顿监测方案》
《微信“红包照片”背后的技术难题》
《移动端IM实践：iOS版微信小视频功能技术方案实录》
《移动端IM实践：Android版微信如何大幅提升交互性能（一）》
《移动端IM实践：Android版微信如何大幅提升交互性能（二）》
《移动端IM实践：实现Android版微信的智能心跳机制》
《移动端IM实践：WhatsApp、Line、微信的心跳策略分析》
《移动端IM实践：谷歌消息推送服务(GCM)研究（来自微信）》
《移动端IM实践：iOS版微信的多设备字体适配方案探讨》
《信鸽团队原创：一起走过 iOS10 上消息推送(APNS)的坑》
《腾讯信鸽技术分享：百亿级实时消息推送的实战经验》
《IPv6技术详解：基本概念、应用现状、技术实践（上篇）》
《IPv6技术详解：基本概念、应用现状、技术实践（下篇）》
《腾讯TEG团队原创：基于MySQL的分布式数据库TDSQL十年锻造经验分享》
《微信多媒体团队访谈：音视频开发的学习、微信的音视频技术和挑战等》
《了解iOS消息推送一文就够：史上最全iOS Push技术详解》
《腾讯技术分享：微信小程序音视频技术背后的故事》
《腾讯资深架构师干货总结：一文读懂大型分布式系统设计的方方面面》
《微信多媒体团队梁俊斌访谈：聊一聊我所了解的音视频技术》
《腾讯音视频实验室：使用AI黑科技实现超低码率的高清实时视频聊天》
《腾讯技术分享：微信小程序音视频与WebRTC互通的技术思路和实践》
《手把手教你读取Android版微信和手Q的聊天记录(仅作技术研究学习)》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（容灾方案篇）》
《腾讯技术分享：GIF动图技术详解及手机QQ动态表情压缩技术实践》
>> 更多同类文章 ……
（本文同步发布于：http://www.52im.net/thread-2050-1-1.html）