[原创]个人理解，请批判接受，有误请指正。转载请注明出处: 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. 读写分离

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

[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/%E5%A4%A7%E6%95%B0%E6%8D%AE/ES-work-principle.html

本篇主要针对ES以下内容进行分析

1. 写过程
2. 读过程
3. 读过程-索引原理
4. 倒排索引
5. es为什么快

以下后续有缘补充
5. 写入数据时的底层数据
6. 更新/删除数据时的底层数据

1. 写过程

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/system/how-to-improve-service-availability.html

低层次的说，大概有如下方法

• 容灾(lvs+keepalived等)
• 负载均衡+心跳
• 限流
• 熔断&降级
• 重试
  • 业务重试
  • 框架切换节点重试等
• 监控+预警
  • 业务上下游流量监控+接口流量监控
  • JVM等指标监控
  • 指定日志监控
  • 主动发送预警
• (补充)解耦:动静分离/前后分离

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

性能优化核心思想

1. 网络传输上

1. 选择合适的传输协议，如Http->dubbo，以二进制传输+长连接请求
2. 开启序列化、压缩等，对于大数据量的传输可能有特别大的提升
3. 对于重复请求同一个url的连接池，使用长连接
4. 对于不需立即响应的，使用异步请求
5. 对即时聊天等双向实时性要求高的，使用webSocket全双工等

2. JVM

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

接: Redis-Sentinel总结

背景

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

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

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

1.Redis主从架构

1. 主节点负责写入操作
2. 从节点可以提供读取操作(可配置,有延迟,高一致性的场景下需要注意)

2.Redis主从复制流程