| 亿级别消息存储 | ✔ | ✔(可以通过分库分表支持) | ✔ | ✔ | ✔ |
| 单条消息查询 | ✔ | ✔ | ✔ | ✔ | ✔ |
| 根据用户/组/模板/时间/其他业务字段 分页查询消息 | ✔ | ✔ | ✘ | ✔ | ✔(有查询限制) |
| 消息更新(更新确认时间/消息状态/发送结果) | ✔ | ✔ | ✘ | ✔ | ✔ |
| 根据用户/组/模板/时间/其他业务字段 统计各个维度的消息发送情况 | ✔(支持简单的全文检索) | ✔(不支持全文检索，会有性能瓶颈) | ✘ | ✔(会有性能瓶颈，不支持全文检索) | ✔ |
| 事务原子性保证(多条写入/更新场景) | ✔(仅支持批量事务) | ✔(支持完整的事务) | ✘ | ✘ | ✘ |
| 支持并发查询 | 单节点上万QPS | 单节点上万QPS | 单节点上万QPS | 单节点上万QPS | |
| 可扩展性 | ✔(支持前端/后端分别扩展) | ✔ | ✔ | ✔ | ✔ |
| 查询响应时间 | 通过优化可达到亚秒级 | 通过优化可达到亚秒级 | 通过优化可达到亚秒级 | 通过优化可达到亚秒级 | |
| 实时写入性能 | 通过优化可达数十万每秒 | 通过优化可达数十万每秒 | 优化后可达上百万每秒 | 优化后可达数十万每秒 | 比较拉胯，优化后勉强能达万级别 |
| 后端使用难度 | 兼容mysql协议，入门简单，使用难度较低 | 简单，后端很多项目都在使用 | 没有尝试过作为数据库来用，使用经验少，难度较高 | 简单，后端很多项目都在用 | 简单，后端很多项目都在用 |
| 学习成本 | 兼容mysql协议，入门简单，简单使用学习成本较低 | 极低 | 简单使用学习成本较低 | 简单使用学习成本较低 | 简单使用学习成本较低 |
kafka用于消息队列是合适的，但是对于数据的查询分析和修改场景支持都比较弱，无法满足业务场景
Elasticsearch和mongo都无法保证事务原子性，对于多条数据批量新增和更新场景无法保证一起成功，Elasticsearch的写入性能拉胯但可以通过延迟批量写入来弥补，mongo对数据分析场景支持比较弱
mysql是比较全面的且后端对mysql的掌握都很好，缺点就在于在单表数据量较大时性能会急剧下降，且对数据分析场景支持一般
doris对全文检索支持不是很好且不支持完整的事务，但是相较而言比较全面，特别是在数据分析场景比较出色，从长远考虑未来应用程序与大数据结合使用的场景还是很多的，用消息中心来试水风险比较小
方案一：mysql+doris组合存储，mysql存储配置信息(渠道、模板、策略、发送人、组信息等)，doris存储发送的消息信息(发送请求、发送结果)用于查询和分析，doris单表可支持亿级别数据，且写入性能查询性能各方面都不错，比较均衡，与mysql互补很合适
方案二：mysql+elasticsearch也可以满足所有业务场景，只不过mysql在单表数据量达到五百万级别后性能会急剧下降，需要额外设计一套分库分表方案来保证性能，架构的复杂度较高；Elasticsearch的查询性能很好，后端对es的使用也很熟练，写入性能可以通过延迟批量写入来弥补，二者可作为互补
倾向用第一种方案组合存储