这是七米老师的一个课程项目。
主要讨论的是两个场景下的评价和评论系统。
电商场景下评价系统
电商类评价系统主要侧重对商品的描述、质量、价格等⽅⾯的评价，需要有关联的SKU/SPU和订单等信息，
数据⽅⾯更强调标签化，好评数、中评数、差评数等。
UGC社区评论系统
UGC区的评论可以包含更多维度的信息，不仅有⽂字还可以添加图⽚、视频等多媒体信息，评论数据则以数
量、点赞数、回复数等形式进⾏统计，更注重⽤户的互动和参与度。
相同点
从技术上看都是用户对一个对象发布关联信息。
电商评价中的输入输出
模块划分
C端：⽤户端，包括发评⽤户和看评⽤户。
B端：商家端，店铺商家端，店铺管理者，商品发布者。
O端：运营端，运营同学在运营后台负责审核⽤户评价，处理商家申诉，以及基于评价进行运营活动。
架构图分为 请求入口层 → 业务服务层 → 存储与缓存层 → 搜索与任务处理层 四个部分。
请求入口层：在这里实现鉴权、限流、熔断、日志记录等跨切面关注点，保证内部服务的安全与稳定。之后将请求转发后面对应的微服务（review-c, review-b, review-o）。
业务服务层，review-c (Review-Customer), review-b (Review-Business), review-o (Review-Order)。根据业务维度进行拆分。例如，review-c负责用户侧评价的展示和发布，review-b负责商家后台的回复与管理，review-o负责与订单流程相关的评价逻辑。这种拆分避免了服务过于臃肿，便于独立开发、部署和扩缩容。他们都通过调用review-service对数据进行处理。
review-service负责所有评价的核心逻辑：
写入数据 → 将评价写入 MySQL。
缓存加速 → 将热点数据写入 Redis，避免频繁查询数据库。
搜索与查询 → 调用 Elasticsearch，支持复杂搜索（比如关键词搜索、模糊匹配）。
与其他业务模块交互 → 通过 gRPC 和 review-c/b/o 服务协作。
数据处理与异步化层
这是保证系统高性能和可扩展性的关键。
- Canal + Kafka (数据同步与消息队列)
工作流程：
Canal：伪装成MySQL的从库，实时监听并解析MySQL的binlog，当write服务向MySQL写入新的评价数据后，Canal能立刻捕获到这一行数据的变更。
Kafka：Canal将变更数据作为消息发送到Kafka消息队列中。
好处：
解耦：write服务写完数据库后就返回成功，后续所有依赖新数据的操作（如更新缓存、构建搜索索引）都通过消费Kafka的消息来完成，与主流程完全解耦，不会阻塞用户请求。
异步化：实现了最终一致性模型，系统吞吐量更高。
- review-task (异步任务服务)
角色：作为Kafka的消费者，订阅评价数据变更的消息。
职责：它负责执行各种耗时或非实时的任务，例如：
更新Redis缓存：消费消息，将最新的评价数据更新或预热到Redis中，保证下次read服务能读到新数据。
更新搜索索引：将变更数据同步到reviewsearch（可能是Elasticsearch）中，用于支持复杂的评价搜索功能。
- reviewsearch (搜索服务，如Elasticsearch)
用途：专门用于处理复杂的评价搜索查询，比如“搜索包含‘物流快’关键词的五星评价”。Elasticsearch的倒排索引特性使得这类查询非常高效。
可以看到两者的分层都差不多，区别在于UGC先写入kafka。
为什么两者不同
- 电商评价系统（写 MySQL）
电商评价的特点是：
数据量相对较小（用户下单后才会评价，不是随时都能发）。
业务上要求强一致性（评价必须实时写入数据库，保证用户一提交就能看到）。
所以选择 同步写 MySQL，再通过 Canal 同步到 ES。
- UGC 评论系统（写 Kafka）
UGC 评论的特点是：
评论量大、并发高（随时随地发评论，量级比电商评价大得多）。
允许一定程度的最终一致性（评论写入后，稍晚一点出现在页面上可以接受）。
通过 Kafka 解耦，能抗高并发，同时异步落库和构建缓存。
