生产数据库扩库

发表于2021-05-02|更新于2021-08-10|design

|浏览量:

[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/design/database-scale.html

背景

文章作者: 花火

文章链接: https://heyfl.gitee.io/design/database-scale.html

版权声明: 本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源花火笔记！

优化 MYSQL 架构设计 MYCAT

相关推荐

缓存密集加载导致数据库崩溃问题

[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/Bug-Log-Optimization/cache-load-database-crash.html 背景 SISP自己基本不存储业务数据，但是每个节点都需要本地缓存了一些网点、员工信息、月结用户信息等基础数据，生产监控发现数据库定期压力飙升，数据库CPU压力到达80+%如图：用脚趾头分析从图中可以看出，每天小时飙升一次，明显就是定时任务大批量查询数据库导致的，在SISP系统，也就只有加载缓存可能会导致找到运维获取慢日志，发现大量的查询语句，如下： 12345SELECT DISTINCT nd.division_code AS city_code, nnd.dist_cn_name , nnd.dist_en_name FROM tm_new_district nd, tm_new_district nnd WHERE nd.division_code IN( SELECT DISTINCT t.CITY_CODE FROM t...

ES文档结构优化

[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/design/es-structure-optimization.html 一个不错的优化：背景因为我们对订单的ES索引模板中，orderExtendInfoList存储多个扩展属性，用作外部订单号、二程运单号等信息的存储，业务上需要对其作为条件进行索引，为此我们把他设置为嵌套nested类型。偶然学习发现这种嵌套nested类型会导致每个订单下的orderExtendInfo都会生成多个文档，导致索引数据量放大几倍，会导致查询性能下降，故重新设计进行优化。优化ES存储订单数据的结构把orderExtendInfoList打平并改为keyword类型（原来为嵌套类型）, 内部额外存储一个作为索引用的值为原orderExtendInfo的key和value对应的Map 描述起来比较麻烦大概是把下图左边的变成变成右边的效果 4亿+数据量减少到只剩下5kw数据量，降低了十倍左右查询时的CPU与内存压力均降低10%左右

【Hbase优化_1】HBase 行键设计优化：解决数据倾斜问题

[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/design/hbase-region-data-skew.html 这次分享/记录如何通过优化行键设计来解决 HBase 中的数据倾斜问题在大数据场景下，我们的系统使用 HBase 存储了大量的巴枪信息。其中巴枪信息分布在两个表中，分别是巴枪索引表和巴枪主表。生产中经常会出现Hbase超时问题，用户也经常反馈原始路由查询、巴枪扫描数据导出等功能查询时间过长、超时等问题。经过分析，发现这些问题的根本原因是 HBase 数据倾斜问题。 1. 巴枪信息表结构 1.1 巴枪索引表表结构 rowKey: [3位0~499分区号][5位网点编码]|[4位巴枪码]|[操作14位时间字符串]|操作号 value: 巴枪主表的rowkey 示例 rowKey: 2700755W|0030|202204060000129|031801088694 1.2 巴枪主表表结构 rowKey: [3位0~499分区号][12位运单号]|[4位巴枪码]|[14...

Hystrix熔断优化

[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/design/Hystrix-optimization.html 简述本文说的其实就是合理配置熔断，防止依赖的第三方接口响应过慢导致系统tomcat链接大量阻塞，最终导致系统崩溃的问题顺便，将熔断配置从配置文件中提取出来，动态配置中心中，这样就可以通过动态配置中心来动态配置熔断参数了除此，主要是团队里大家对单线程并发数与QPS概念有些混淆且计算方式了解不多，以及信号量与线程池方案选择上有些歧义，需要花了不少时间在会议上让团队达成一致。背景&分析问题 SISP客服系统、SISP查单系统等系统提供的服务都通过HTTP依赖于大量外部各种接口的响应，这些接口的响应时间不可控，有时候会出现响应时间过长的情况，这时候如果不做任何处理，那么这些请求就会一直等待，这样就会导致系统的响应时间过长，甚至出现系统崩溃的情况。双十一期间，SISP客服系统出现了系统崩溃问题，经排查发现tomcat线程池被耗尽，进一步排查是因为所依赖的PIS接口响应慢了简单来说问题大概长...

（零拷贝）优化转发型文件下载

[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/design/zero-copy-file-download.html 背景现有报表系统异步导出报表，生成的报表会上传到对象存储中，因为安全问题，用户不能直接上对象存储系统中下载文件，需要通过报表服务代劳，因为不需要对其做修改，只需做转发，所以这里考虑使用零拷贝技术进行优化现有做法把文件数据『下载』下来，然后把对应的文件返回给客户端数据经过两次拷贝，一次是从对象存储下载到报表服务，一次是从报表服务下载到客户端 12345678910111213141516@Controllerpublic class DownloadController { @RequestMapping(value = "/download", method = RequestMethod.GET) public ResponseEntity<byte[]> downloadFile() throws IOException {...

前后端合并可行性

[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/design/front-end-merge.html 这里描述的是前后分离，非动静分离简单放图，日后完善描述前后端分离优劣为什么要使用前后分离微服务：1个或多个后端为多个前端服务安全：保护后端接口，防止暴露后端IP 提高吞吐量：后端压力大，需要支持水平扩展，多个后端提供服务分担压力劣势部署麻烦：需要前后分离部署，节点数*2 增加开发工作量：约20%的工作量查错麻烦：查询日志需要前、后端日志一并查询分析结果前后分离更多的是为了保护后端，并且更多的是为了水平扩展，提高后端吞吐量。但实际业务上只对内部用户开放，无太多安全需求，对并发需求也不高，前后分离没有带来更多收益，反而增加了不少工作量与资源浪费，因此将前后端合并。