随记

用户量级推荐策略数据架构开发人月< 100 人人工配置+共现SQLMySQL0.2100 ~ 5k离线共现矩阵+定时任务MySQL+定时任务15k ~ 50kItem-CF + Redis缓存MySQL/ClickHouse + Redis + 每日训练2~3> 50k实时+离线混合，深度学习Kafka + Flink + Hive + ES向量检索6+核心原则：不超前设计，量级到了再升级。

分区数要大于消费者数？答案是：正确，但它是一个“底线”规律，是为了防止资源浪费。在实际架构设计中，我们追求的是一个更优的实践：根据你期望达到的最大消费并发能力来设置分区数，并确保分区数 >= 最大消费者实例数，同时为未来扩展预留一定空间。分区数决定了你消费端并行能力的上限。设置的消费者实例数不应超过这个上限，但可以根据实际负载动态调整（例如在流量低谷时减少实例数以节省资源）。

设计原则具体技术解决的问题带来的好处利用顺序 I/O仅追加日志磁盘随机读写慢极高的磁盘吞吐量减少数据拷贝零拷贝CPU 和内存带宽瓶颈低 CPU 占用，高网络吞吐合并小操作生产/消费批处理，数据压缩网络和磁盘 I/O 效率低高吞吐量，节省带宽和存储利用 OS 特性页面缓存，异步刷盘JVM GC 开销，写放大低延迟读写，低 GC 压力实现水平扩展分区机制单机瓶颈高并发，可线性扩展快速数据定位稀疏索引海量数据下查找慢快速消息检索，节省存储。

MQ（MessageQueue，消息队列）是一种 FIFO（先进先出）数据结构，用于跨进程传递数据。典型 MQ 系统中，生产者将消息发送至 MQ 进行排队，并按顺序由消费者处理。以 QQ 和微信为例（面向人类用户），而 Kafka 则面向应用程序。异步：提升系统响应速度与吞吐量。例：快递员将快递放入菜鸟驿站即可继续工作，收件人按需自取，无需等待。解耦：减少服务间依赖，增强系统稳定性与扩展性，支持数据分发。例：出版社将英文书籍翻译为多语言版本，实现跨语言信息传递。削峰：以稳定系统资源应对突发流量。

特性KafkaRocketMQ服务发现使用ZooKeeper使用NameServer消息存储按分区存储所有消息存储在CommitLog，逻辑队列存储索引消息过滤基于分区基于Tag和SQL表达式消息顺序分区内有序队列内有序事务消息支持支持更完整的事务机制延迟消息有限支持支持18个延迟级别消息重试需要自行实现内置死信队列和重试机制这些图表和说明展示了Kafka和RocketMQ的核心概念和架构差异，帮助理解两者的设计哲学和适用场景。