接着上一篇文章，架构方案如下：先上图，再对关键点逐一解释
基于可更新的邮件设计.png
流程解释如下
- 红色表示邮件发送流程，绿色表示用户打开邮件的流程
- BDP将数据推送给MySQL后，等待数据稳定后，用定时任务将数据同步ES
- ES可先采用单库多索引的方式，索引可基于模板每月初定时创建，month_bill_year_month
- 用户打开邮件时，邮件实时请求账单数据服务，核心参数为：pin，year，month
- 为保证性能，数据请求还是先走缓存，缓存不存在，则走ES或者MySQL，缓存时间为1个月
缓存key-value参照<pin_year_month,data> - 如果请求的上月账单，则从MySQL取，否则从ES取
- 如果涉及数据更新，则数据推送完毕后，需要更新缓存
性能保证
- 数据都从缓存取，性能可以保证
- 缓存失效时，上月账单从MySQL取，性能可以保证
- 上月的数据，从ES取，虽性能不比MySQL，但是由于这种场景少，可以接受
性能优化
- 缓存可采用预写入，就是发送时写入，但是邮件的打开率如果不开，那么缓存的命中率也低，意义不大
不满足场景
- 如果用户第一次看到的邮件是错的，但是邮件客户端缓存已经开启，用户如果不手动清除缓存，看不到修正后的邮件数据
法务风险
- 从业至今还没有见过收到邮件后，内容又变了的，此处需要咨询法务，是否涉嫌篡改
网友评论