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

背景

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

现有做法

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

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

接: Kafka延时队列方案探讨

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

背景

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

Snappy压缩方案

研发环境(redis单节点，两个哨兵)

1. 压缩率

压缩前的redis内存：

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

1、 CPU性能对比（通过对比CPU时间）

对比论证：

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

除此，还有一个比较好的优化，见： ES文档结构优化

背景

难得有数据留存,写一篇^_^

原逻辑

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

常见的三类高并发场景

高并发压力主要来自,并发时出现大量锁冲突

1.细颗粒度操作-锁冲突少 如:QQ微信等即时通讯业务个人读个人自己的数据

数据结构