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

接: 冷热分离场景分析&实际业务落地

前言

在数据库的读写研发中，我们遇到最多的可能就是数据量过多导致的『读/写慢』了。针对这些问题，我们一般主要会采取的措施有：

1. 优化SQL
2. 优化索引
3. 优化硬件
4. 分库分表
5. 业务拆分
6. 冷热分离
7. 读写分离

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

前言

在数据库的读写研发中，我们遇到最多的可能就是数据量过多导致的『读/写慢』了。针对这些问题，我们一般主要会采取的措施有：

1. 优化SQL
2. 优化索引
3. 优化硬件
4. 分库分表
5. 业务拆分
6. 冷热分离
7. 读写分离

这次我们主要讲讲冷热分离的实际使用场景，以及如何以前刚出来时候的项目实际落地方案。

type: drafts

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

这里主要是以订单超时取消为例

粗略记录，日后完善

1. 取消任务先加入数据库（持久化存储）,后加入当前节点时间轮（本地内存）
2. 通过时间轮任务,触发订单取消逻辑、同时把数据库的任务删除
3. 节点重启后，先通过数据库加载属于自己节点的任务到本地时间轮 注意，此处存在一些已经超时的任务，需要加载的时候顺便执行取消订单逻辑，把过期的任务从数据库删除
4. 节点的时间轮恢复，后续继续通过1. 2. 步骤继续运行

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

先粗略写，日后有缘完善

背景

上游系统在推送数据到下游系统时,由于网络、代码、又或者是运维上（主要是sql重推没去重之类的），导致上游短时间推送大量同一单号给到OMS系统，导致数据库压力剧增

解决方案

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

背景

考虑到部分场景可能需要强一致性缓存：

后端更新时，需要保证使用端查询缓存时立马就能查询出最新的缓存值，且需要考虑并发场景导致的不一致情况

所谓的『强一致性』问题确认

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

接: Redis-Sentinel总结

背景

介于Redis-Sentinel的高可用性，我们在顺丰内部的Redis集群中，大量使用了Redis-Sentinel来保证Redis的高可用性
但是由于Redis主从的复制是异步的，从节点数据略微落后于主节点数据，为了业务的一致性，一般从节点是闲置的，也就是说不会做读写分离

但这种情况下，Redis的最高吞吐量会被限制死在单机的吞吐量上，这对于一些高吞吐量的业务来说，是不够的。 因此有了下面的架构

[原创]个人理解，请批判接受，有误请指正。转载请注明出处: 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/design/zero-copy-file-download.html

背景

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

现有做法

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