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

今天来介绍一个不错的优化：

背景

因为我们对订单的ES索引模板中，orderExtendInfoList存储多个扩展属性，用作外部订单号、二程运单号等信息的存储，业务上需要对其作为条件进行索引，为此我们把他设置为嵌套nested类型。
偶然学习发现这种嵌套nested类型会导致每个订单下的orderExtendInfo都会生成多个文档，导致索引数据量放大几倍，会导致查询性能下降，故重新设计进行优化。

优化ES存储订单数据的结构

参考主要来自58沈剑←
[知识整理]根据个人理解整理后分享，请批判接受，有误请指正。转载请注明出处:
https://heyfl.gitee.io/design/Weibo-feed-design.html

什么是Feed流

Feed流即持续更新并呈现给用户内容的信息流 , 对于微博.微信朋友圈等业务刷新的数据都为Feed流
每条微博 朋友圈 为一条Feed

关键动作,关键数据

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

s

目前在用方案:直接重新丢回队列后面

实现逻辑

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

这里描述的是前后分离，非动静分离
简单放图，日后完善描述

前后端分离优劣

为什么要使用前后分离