项目开发完之后，优化升级的一些思路

笔者的工作经验总结。

1、发生场景：某些dubbo接口出现时快时慢，极限情况出现超时的情况。

      排查：

        1、链路追踪日志追踪skywalking追踪发生问题的服务接口。

        2、借助阿里 arms 工具穿透dubbo层，直接定位到某个dubbo服务内部具体出现慢的方法。

        3、现象（dubbo protocol层编解码慢的场景）

       解决方案

                1、dubbo传输数据包大（大对象切割为小对象传值），有些项目可能需要存在使用dubbo filter进行服务之间的传值，或者服务方和调用方传值的情况，底层实际就是Threadlocal之间的传值，注意使用完之后一定要做remove操作，否则会直接引发内存泄漏的场景。

                2、理论（非验证阶段，只针对框架）：dubbo编解码没有做水位控制（dubbo wrapper数据写到协议管道，netty没有做限制），参考rocketmq设计做双水位管控，即dubbo protocol 水位控制一层，netty内部设计水位控制。双管控水位控制超过阈值，直接实施降级处理，或者做警报处理。

      经验之谈：明显理论5上的设计跟不上业务迭代，该方案复杂化处理了，可以择快解决。

2、批量业务并发场景生成批量分布式id性能耗费时间过长。

      redis做分布式id一定会涉及到几个步骤，

        hget/hscan 

        hexist 

        hset  

        假设用户需要下一万单，需要生成一万个分布式id，这就意味着需要整整3W个命令，存在并发场景，由于redis本身单线程处理，一定会导致效率低下。

        排查：skywalking就可以了。

        解决思路：减少分布式id在redis的操作，尽量使用内存进行操作，保证内存级别的线程安全即可。

        只生成一个分布式id，分布式id+自增1w，这个操作必须保证线程安全，可以使用redisson redlock来保证。

数据分为两个层面设计

1、热点数据使用redis

2、非热点数据分库分表（建议分表数据500w，实操：越少越好，理论不等于实际，100万就可以了）、数据库层面读写分离、主从同步（主从延时，可以增加一台salve做冷备处理即可，对外不可读）。

3、千万级数据量：

        1、mysql + 分库 + 分表 + 读写分离 + 主从同步 ，msyql尽量设计较大的buffer pool，可以直接设计最大的线程池连接数。

        2、oracle ：千万级单表查询性能可以，但一般公司不会使用，要钱。并发事务插入更新千万级也可以达到2-3秒。

        3、mysql + binlog + es （传说可以处理亿级，实际千万级还算稳定，cpu嘎嘎的）