亿级数据量系统优化思考

编程并不是一个机械性的工作，而是需要有思考，有创新的工作，语法是固定的，但解决问题的思路则是依靠人的思维，这就需要我们坚持学习和更新自己的知识。今天golang学习网就整理分享《亿级数据量系统优化思考》，文章讲解的知识点主要包括MySQL、Java，如果你对数据库方面的知识点感兴趣，就不要错过golang学习网，在这可以对大家的知识积累有所帮助，助力开发能力的提升。

技术层面

【配置项】抽离主库，或永久放置于缓存中，guava或redis或二者同时使用皆可（高并发时需要考虑redis最大连接数等瓶颈，小数据量配置项可以考虑仅使用本地缓存），在配置项发生变化时刷新缓存，可透过广播（Dubbo）通知所有实例刷新本地缓存，以降低C端接口调用时间

【数据库】视业务情况，配置数据库链接最大数等于初始量，即程序运行过程中不进行新申请数据库链接的行为，可避免在高并发情况下，大量请求同时获取数据库链接导致的竞争耗时

【SQL】在大数据量情况下，当索引对应过多数据会导致索性性能下降，甚至全表扫描，在内存情况允许时（即运行实例可以承受的内存空间，空间换时间），可用代码过滤来代替数据库级别筛选，提高数据库层面查询效率；在coding时应慎重使用not in条件，同时时间类型查询条件可以考虑通过主键进行筛选（业务允许时）

【数据归档】结合实际业务情况，将数据归档，例如半年、一年前的订单数据，两年前已过期的积分流水等非高频数据；可结合数仓，如hive，es等进行冷数据查询

【使用从库】结合实际业务情况，可利用从库完成某些复杂报表统计，当从库延时满足业务接受最大延时的条件下，可完全读取从库数据，如T-1账单，积分统计，门店业绩统计等

【事务】在高并发场景下应更谨慎的确定事务覆盖的范围，例如在某些需要获取锁的场景下，获取不到锁的请求将抛出异常返回，若此时有事务覆盖，则将浪费系统性能，应该将事务覆盖在获取锁之后（事务应只覆盖真正的DB操作区间）

业务层面

【数据时效性】引导产品深入分析业务需求，确定业务接受的最大数据延时，例如报表，或C端数据概览，确立数据时间边界，规避非刚需的实时数据查询

【业务合理性】从功能层面推动业务需求，并非所有需求都是业务决定，当面临大体量数据带来的系统压力，可以考虑从业务角度出发，先将所需处理的数据分解，再拼凑，规避系统性能瓶颈，例如预约数据，可通过发送邮件、生成报表提供下载等形式代替实时生成，在不影响用户体验的情况下，尽可能节约系统性能

优化案例

查询用户基础数据时，查询条件类型多，数据需要通过多个表汇总，敏感信息通常需要解密，故耗时较长，接口性能差；由于代码迭代太久，导致单一方法糅杂了多余的查询，查询慢，经排查发现，不同的查询条件针对某些数据存在多次查询的情况，故对齐进行优化，各项关键数据只进行一次查询，提高了系统性能；过往最高TPS 2800/s，优化后压测TPS 9000/s

消费积分时，为了保持数据唯一性，对userId加锁（即同一userId的请求，必须串行执行）。代码优化前，获取锁之前就已经覆盖了事务，导致高并发时同一userId的第二个请求获取不到锁，代码抛出异常，事务回滚，整个请求的时间延长，性能下降。优化后，在获取锁以后才覆盖事务，大大提高了接口性能，避免了资源浪费

今天关于《亿级数据量系统优化思考》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！