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

简述

本文说的其实就是

• 合理配置熔断，防止依赖的第三方接口响应过慢导致系统tomcat链接大量阻塞，最终导致系统崩溃的问题
• 顺便，将熔断配置从配置文件中提取出来，动态配置中心中，这样就可以通过动态配置中心来动态配置熔断参数了
• 除此，主要是团队里大家对单线程并发数与QPS概念有些混淆且计算方式了解不多，以及信号量与线程池方案选择上有些歧义，需要花了不少时间在会议上让团队达成一致。

背景&分析问题

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

背景

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

随着业务扩张，Hbase使用率越来越高，大数据那边反馈已经没有资源了，全公司都没有了，要扩资源得等公司出去采购，可以的话问我们能否看能不能优化一下Hbase存储，减少一下空间占用。
基于SISP巴枪数据使用业务场景，每行数据是整体从HBase中查询出来，不存在通过字段过滤查询数据、以及只查询某些字段的使用场景，都是将整条数据拿出来、或者整个运单的所有巴枪数据拿出来解析

方案

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

这次分享/记录如何通过优化行键设计来解决 HBase 中的数据倾斜问题
在大数据场景下，我们的系统使用 HBase 存储了大量的巴枪信息。其中巴枪信息分布在两个表中，分别是巴枪索引表和巴枪主表。
生产中经常会出现Hbase超时问题，用户也经常反馈原始路由查询、巴枪扫描数据导出等功能查询时间过长、超时等问题。经过分析，发现这些问题的根本原因是 HBase 数据倾斜问题。

1. 巴枪信息表结构

1.1 巴枪索引表

[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/web/Reduce-half-of-the-cross-domain-requests.html

简述

点很小，作用挺大，简单写写
客服系统重构后，前端对应的后端服务域名不在同一个（这里没有用nginx解决跨域问题），每次请求都会发送两次请求，一次是预检请求，一次是正式请求。
这样就会导致请求的次数增加一倍，这样就会影响到用户的体验，尤其是对网络不好、国外的用户访问体验带来沉重的打机，新版客服系统上线后叫苦连连。

解决方案

这个问题困扰了好些日子，前些天突然查到一个配置可以很很简单快捷的解决这个问题，这个配置是Access-Control-Max-Age

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

背景

现有报表系统异步导出报表，生成的报表会上传到对象存储中，因为安全问题，用户不能直接上对象存储系统中下载文件，需要通过报表服务代劳，因为不需要对其做修改，只需做转发，所以这里考虑使用零拷贝技术进行优化

现有做法

• 把文件数据『下载』下来，然后把对应的文件返回给客户端
• 数据经过两次拷贝，一次是从对象存储下载到报表服务，一次是从报表服务下载到客户端

[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/Bug-Log-Optimization/thread-pool-use-error.html

在生产环境中，我们遇到了一个由线程池配置错误导致的阻塞问题。本文将对这个问题进行详细分析，并提出相应的解决方案。

问题背景

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

背景实在太复杂了。。。简单放图，日后完善描述
一个报表需求由不可为，优化到可行并落地：通过多线程以及业务商讨优化，性能优化百倍以上，并满足业务需求。
除了技术手段外关键在于：通过与业务协商，控制查询范围到15天内、删除不必要的字段、筛选数据等各种业务手段减少查询量、http请求量实现。

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

背景

SISP自己基本不存储业务数据，但是每个节点都需要本地缓存了一些网点、员工信息、月结用户信息等基础数据，生产监控发现数据库定期压力飙升，数据库CPU压力到达80+%如图：

用脚趾头分析

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

其实改动不是很大，这里简单记录下

背景

• OMS订单系统，日数据量较大平均近3kw/日,高峰达8kw+/日的订单需要存到数据库中（之前64库，现在扩到了128库）；
• 运维后台监控看到，各个库的压力不一，江浙沪，京津冀，深圳755等地区对应的数据库压力很高，而其他地区的数据库压力很低；

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

背景