背景

特征 or 全部

在实际需求中，往往存在类似需求：

• 黑白名单；例如手机号、网站等，需要过滤掉在黑名单中的数据，或者放行在白名单中的数据
• 推荐去重；首页新闻、视频等资源已经给用户推荐过的不进行重复推送
• 缓存穿透；保证缓存层能正常工作，不被特殊请求大量造成缓存穿透

最容易想到的，就是通过一个集合例如 Map、List 等结构将数据存储起来，判断是否存在于集合中

背景

管道模式（Pipeline Pattern）是责任链模式（Chain of Command Pattern）的变体；区别在于责任链是将处理器按照链条组织起来，待处理的上下文按照链条找到能够处理自己的处理器，一般只有唯一的一个处理器；而管道模式是链条中的每一个处理器都需要对上下文进行处理

目的 降低业务逻辑流程的耦合性，将整个过程中所有的处理器隔离开，更方便扩展流程上新的业务逻辑

现实世界类比 工厂的生产流水线，车架 -> 发送机 -> 外壳 -> 内饰 -> 总装 -> 质检，整辆车在传送带又一个环节运输至另一个环节，每个处理环节都对汽车处理自己的部分，最终产出成品

实践

Topic 与 Tag

在 RocketMQ 中，Topic 和 Tag 都是业务上用来归类的标识，通过合理的使用 Topic 和 Tag 可以让业务结构清晰，更可以提高效率

Topic 是消息主题，通过 Topic 对不同的业务消息进行分类 Tag 是消息标签，用来进一步区分某个 Topic 下的消息分类，是消息生产时即由消息生产者设置的属性

Topic 和 Tag 的选择，建议从以下几个方面判断：

• 消息类型是否一致：普通消息、事务消息、延迟消息、顺序消息；不同消息使用不同的 Topic，无法通过 Tag 进行区分
• 业务是否相关联：没有关联的业务应该使用不同的 Topic
• 消息优先级是否一致：同一个 Topic 内应该是同样优先级的消息
• 量级是否相当：业务量小但实时性高的消息和业务量大的消息放在一个 Topic 内，可能会导致饥饿

基数聚合

基数聚合属于聚合中的度量聚合，计算不同值的近似计数

需要注意，聚合出的结果是一个近似值，原因是底层结构使用的 HyperLogLog，具有一定误差

基本操作

假定 index 存储的售卖数据，希望查询有多少种不同的商品类型

背景

折叠和聚合

日常会有很多场景希望将平面数据按照一定的条件组合起来，并按照一定规则进行计算

聚合将您的数据汇总为指标、统计或其他分析

可以帮助你回答类似如下问题：

from size

from size 是最常见的分页方式，类比 MySQL 的 offset limit

由于 ES 是天然分布式的，数据分散在各个 shards 上，所以需要查询 from + size 的条数时，coordinate node 就向该 index 的其余的 shards 发送同样的请求，等汇总到 (shards × (from + size)) 条数时在 coordinate node 再进行一次排序，最终抽取出真正 from 后的 size 条结果

显而易见，当 shards 较多、分页深度很大时，这种方式存在很大的性能问题，这也是 ES 默认深度为 from + size <= 10000 的原因

Routing 机制