记录一次基础组件吞吐能力提升的过程

记录一次基础组件吞吐能力提升的过程 概述：

        由于我们基础组件承载的业务后续会有大数据量进来，其中一张核心的数据表占据80-95%读写 *** 作，经过压测发现当2500tps时就会造成数据库cpu使用100%，导致基础组件出现不稳定，大量服务报错。因此需要对基础组件进行优化。

优化阶段一：MQ引入和数据库升级

       step1:引入MQ异步化，通过谷歌限流控制消费频率（被限流的数据重新丢回队列）

       原因：考虑到我们当时对外提供的服务属于异步服务（可以使用MQ或redis等作存储然后异步处理消费即可），因此第一步将所有的请求丢进MQ 中，然后控制频率，同时保证数据库cpu使用率在80-90%这个区间，同时在消费MQ的过程中确保消息不回丢失。

      step2: 调用接口（投递事件MQ）单独剥离成一个独立的项目，并采用pod方式部署（方便扩容）。同时使用sentinel做外部限流，使用谷歌限流做程序内部限流。被限流的请求会给出投递失败相关提示，因为时间比较紧我们在此处接口并没有token令牌限制（令牌许可的应用可以进行投递事件，防止未知流量和业务进来）

       step3: 联系DBA和老大升级数据库

       step4：压测验收

         过程：3500tps，投递程序（投递事件API）运行正常，5000tps，触发sentinel和谷歌限流效果（限流生效）MQ出现消息堆积现象，数据库CPU表现稳定，rt平稳（请求时间）。持续30分钟后关闭压测，消费完MQ比对数据量一致。后续没有继续往上压，因为我们目标2600tps。

优化阶段一结果：

        1.改造后压测个方面运行平稳，运行状况符合预期，改造成功

        2.数据库压力依然存在，同时大数据量的表查询效率比较缓慢，数据库（MYSQL）依然是我们基础租价服务能力的限制瓶颈，我们可以随意的扩展API投递接口，但是不能够随意的扩展基础组件（消费投递的事件），否则依然会很快的造成CPU使用100%

优化阶段二：如果使用MYSQL限制了基础组件的处理能力，那么我们能做的只有一件事                                                —— 替换它

           虽然我们经过一次快速的改造后能够满足现在最大tps吞吐能力，但是不可否认我们依然受制于MYSQL的处理能力，依然很容易就能够达到瓶颈，为什么要让MYSQL限制我们飞的更高，做的更好！！！ 

技术的解决方案和程序猿的圈子一样，有时很大有时就那么大，即便是井底之蛙只要一部手机百度一下也能让你拥有一个世界。

 没吃过猪肉,也见过猪跑，没用过不代表没听过这个NOSQL吧！

目标：使用nosql替换mysql

step1:技术调研

hbase性能参考：

MongoDB性能参考：

 

 step2: 选择方案—hbase

     原因：

                1.我们公司其他业务使用的nosql产品大都是hbase，我们如果使用hbase可以有些成熟的参考

                2.公司运维维护云资源人力成本相对便捷（没办法自己人，你懂的）

 step3:  进行hbase技术调研，小哥之前也没用过相关nosql产品（除了redis，其他文档型的nosql数据库只是了解其结构变更，检索能力，读写能力，扩展能力，稳定性很nice！！）

     问题：

                1.rowkey如何设计（mysql 使用的主键自增，同时使用的类型是int 没错是int，不是bigint这个是组件基础框架默认的，显然这个也是我们要优化的点）

                2.版本，这个使用过hbase同学明白的

                3.大量数据写入时在单个region上会遇到热点问题

                4.如何实现dao曾的hbase业务逻辑

                5.新老服务更替时如何将影响降低到最小，确保数据的完整性（我们的方案是两套DB并存，部署完成后通过开关控制（全局开关和最小粒度开关）保证正常的业务运行不受影响，如果失败只需控制开关即可，做到快速的响应止损）

step4: 改造的逻辑可以参考核心表的DAO层实现来来验证Hbase的DAO是否有问题，避免产生逻辑问题

step5:邀请业务方参与测试和上线验收

总结：

       1.第一次优化主要是时间紧，我们需要在有限的时间达到指定2600tps处理能力，同时保证我们基础组件运行平稳

       2.第二将要做的优化主要考虑后期其他业务开始接入时带来的大数据量和1w以上tps，基础组件如何保证稳定高效的提供服务

       3.基础组件的大版本的改动必须要有专门的测试人员参与测试，以及安排相关业务方参与，同时必须要做压测验收

       4.基础组件必须要做好失败回滚或失败处理方案，同时提前发布上线公告（业务方每次上线也应做好失败回滚和处理方案）

       5.涉及到的新技术，新产品必须要做好技术调研，确保自己在使用的过程不要产生瓶颈问题（例：MQ顺序消费其中一条消息处理失败没有处理导致消费停止，Hbase 热点问题，rowkey，存储方式，版本）否则一旦发生问题可能就是个大坑哦！！！

        6.做好方案评审-设计评审 - 测试评审 -  代码review  前两个环节尽量邀请架构师（两名以上更好）或者技术总监以及测试人员和相关业务方负责人参与

结语：

        希望大家留言沟通自己在开发工作中遇到的问题和你对相关问题看法和解决思路，让我们共同成长，开启我们技术的朝圣之旅。。。。