日邮件发送量千万级，谈京东的 EDM 平台优化之路

EDM 是 Email Direct Marketing 的缩写，即邮件营销。它是利用电子邮件（Email）与受众客户进行商业交流的一种直销方式，邮件营销的对于企业的价值主要体现在三个方面：开拓新客户、维护老客户，以及品牌建设。

京东的 EDM 平台每日发送量千万级别，峰值数据 2T（每日），如何能在峰值到来时保证系统的稳定，以及从大量的邮件发送任务中筛选出高优先级发送任务并及时发送是构建这个平台的难点之一。

老平台日益突出的问题

原有的老平台已经是 5 年前的产物了，受限于当时研发人员对 EDM 的研发经验和当时的技术栈，老平台的几个问题在日后的发展中越来越突出，慢慢的让新架构变成了一件不可不做的事情。

老平台存在的问题如下：

1、技术栈、实现思路混乱

受限于业务，老平台分成了生产邮件和促销邮件两个子平台。对于邮件任务的发送，老促销邮件平台引入了 Thrift 框架，而老生产邮件平台则通过抢占式更新数据库的方式实现。

渲染邮件模板时，老生产使用的是 velocity，而老促销已经改为由上层（邮件模板装修系统）用 handlebars 提前渲染好后直接发送。

2、SQL Server 的改造需求。

老平台的数据库使用的是 SQL Server，从降低公司成本的角度出发，有尽快迁移到 MySQL 的需求。

3、历史需求包袱很重。

很多业务已经下线，但是代码还留在线上（包括各种关联系统）。

新平台：业务架构的确定

在这样的情况下，我们决定抛弃老的平台，构建新一代的 EDM 平台。那其中第一步就是确认业务架构。

新平台将由生产平台、发送平台和统一管理平台组成。生产平台负责生产邮件发送任务，发送平台则部署在主流运营商的网络上，冗余部署一定量的发送节点，保证发送成功率。因为邮箱服务提供商通常会对邮件的发送方按 IP 做流控限制，并且对各种网络运营商投递的邮件的接受程度也不一样。

同时，为了保证在主流的网络运营商渠道上都有发送节点，避免因某个网段或某个运营商网络故障引起邮件发送成功率的波动。所以将发送和生产的逻辑区分开，有利于应用区分部署和扩容，平台间的职责也更加清晰。

老平台也是生产和发送分成两个平台，只不过职责没有划分得非常清晰，比如各自的平台上都集成了管理功能，发送节点只能调节自己的发送策略，不利于发送策略的批量调整。

生产平台和发送平台间使用 Redis 队列传递邮件任务。设计期间考虑过 MQ，Kafka 类组件，没有使用的原因是以上组件对于传递邮件的任务都“过重”，引入新的组件意味着新的风险，新组件的稳定性也会影响平台的稳定性。同时 Redis 对队列有原生的支持，作为当前最常使用的组件，起简单易用的特点正好符合新架构对这个组件的要求。再加上公司已经对 Redis 实现了集群及自动伸缩方案，可用率大大提高，学习零成本，都是 Redis 的优势，也是这次架构升级选用 Redis 的理由。

建立统一管理平台，实现对生成和发送情况的统一调度。要求是实现对整个生产和发送平台的调度管理，包含指定高优节点，屏蔽成功率较低节点，降级开关等一系列措施。

经过多次梳理和方案推导后，整个 EDM 平台的业务架构如下：

生产平台对接用户组，订单组，会员等系统的 MQ 消息或远程调用生成邮件发送任务，并按类型划分 1-10 个优先级，数字越大，优先级越高。

Redis 按优先级和目标邮箱两个维度拆分成多个 Redis 队列，负责将邮件任务传递到发送平台。

发送平台聚焦在发送业务的处理上，包括优先级队列、发送降频、邮件模板渲染等事务。

管理平台主要负责配置数据的维护、降级开关的推送和必要时人工对生产、发送平台的调度。

方案细节

1、Redis 优先级队列

首先，业务上决定了邮件任务的紧急程度是不一样的，例如用户对账户密码找回的邮件就比优惠券到账的及时性敏感度更高，显然密码找回的邮件需要以最快速度投递到用户邮箱中。这和某些在极端场景才出现的“优先级”不一样，是一直持续存在的高优任务，最简单的办法就是区别对待，按优先级设置队列，从生产平台开始到 Redis 队列再到发送平台都一直是一个或多个特殊的队列，方便系统对这些高优发送任务做处理。

同样，高优先级队列长度的报警阀值比较小，一旦积压研发同学会第一时间收到报警，必要时可以人工接入。而发送平台总是最先拉取高优先级发送任务，保证其第一时间被处理。值得注意的是，从客观规律上看高优的邮件往往量是比较小，这使得发送平台总是优先处理高优的邮件并不会让优先级低的发送任务没有机会被拉取。

当业务量较大，发送较为频繁时触发邮件服务商的流控，或网络不稳定，出口 IP 异常时都会引起部分发送平台的邮件投递成功率的下降，这时需要让成功率将低的节点暂时甚至永久的不再向邮件服务商投递邮件，解决方案之一是在队列的拆分维度除了优先级以外再增加一个目标邮箱，一旦出现上述问题后，可以直接让发送节点不再拉取该邮箱的所有队列来实现故障隔离。

同时，用优先级和目标邮箱拆分 Redis 队列还有一个好处是，如果使用的是分布式的 Redis，队列的元素总是在一个分片中的，如果队列过少，会导致有可能大量元素都集中在同一个分片中形成热点分片。将 Redis 队列拆分后可以让分个分片的读写相对更均衡，分片的利用率更高。实际上，Redis 队列还设置了一个最大长度，防止队列无限制的增长。

2、投递降频

投递邮件时如果投递被拒绝邮件服务提供商一般都会返回一个错误码，发送平台上有一个错误映射表，发送错误后将错误码和错误映射表比较，如果触发了流控则降低邮件发送任务的拉取频率，直到投递成功率恢复后再逐步提升发送能力。

3、Checker

Checker 是生产平台扫描邮件发送任务的定时任务的总称，按职责不同，Checker 被具体分为 UnsuccessChcker、InQueueChecker、ExpireChecker 等等。职责是将各个状态的邮件发送任务更新为下一个流程需要的状态，比如将入库成功的状态更新为 Redis 队列中，Redis 队列中更新为发送平台发送中，发送错误的任务更新为重新投递等等。

重新投递是非常重要的一个功能，因为某个出口 IP 因为各种原因可能会常常被邮件服务商拒收，重试相当于有较大几率更换出口 IP 再做发送尝试，有利于投递成功率的提高。因为邮件发送任务常常被各种 Checker 更新，为了保证数据的一致性和状态按正确流程流转，邮件发送任务被加上了版本号，每次更新后自增，更新时使用乐观锁更新。

性能优化

初期平台上线时的第一版架构如下：

上线后出现了一系列的性能问题，总结起来主要为两类。

第一类问题：写库 CPU 100%，影响远程调用接口的性能，引发上游团队关注。

引发写库 CPU 100% 的原因最主要的还是数据库同一时间读写请求太多和索引利用率不高导致的。因此第一步想将数据库的读写压力分开，对数据库做了读写分离，所有的读请求全部调整到了从库上去，以此降低主库压力。这里有一个前提是经过评估，从库读取脏数据并不会对业务产生困扰，因为邮件发送任务本身有版本号，即使数据库主从同步有延迟引起从库读到“脏数据”使用乐观锁更新时也会失败，不会引起业务错误。

第二步将查询条件归一再后建立索引，索引不是越多越好，归一时可以现将查询任务列出来，观察哪些查询条件是相似的，有没有特殊的业务导致了不一样的查询条件，这些业务有没有办法从其他角度去支持，逐步归纳后再建索引。上述步骤多次使用后，通常情况必须要建立的索引就不会太多了。目前邮件发送任务表（分表后单表千万级）只有一个主键索引和一个组合索引（三个字段），所有查询条件全部先利用索引查询数据。

调整完索引后发现 Checker 的扫描还是过于频繁，读库 CPU 利用率还是不够理想（过高），梳理业务后发现整个平台的发送能力取决于邮件服务商的接受量和一定程度的发送平台量（出口 IP 量）。两者不变的情况下，整个发送平台的发送量不会提升，Redis 队列的吞吐能力也不变，Checker 大部分时候运行的结果只是 Push 了个别元素，甚至没有 Push。Checker 完全可以改成 Redis 队列小于一定阀值，例如最大长度的 1/2 再做一次扫描，一次扫描尽量将队列填满。调整 Checker 策略和索引后数据库的 QPS 大约降了 2/3，load 也稳定在 5 以下。

还有一个让数据库 CPU 较高的原因是 Checker 引起数据库死锁。

例如有 Transaction1 需要对 ABC 记录加锁，已经对 A，B 记录加了 X 锁，此刻正尝试对 C 记录加锁。同时此前 Transaction2 已经对 C 记录加了独占锁，此刻需要对 B 记录加 X 锁，就会产生数据库的死锁。

尽管 MySQL 做了优化，比如增加超时时间：innodb_lock_wait_timeout，超时后会自动释放，释放的结果是 Transaction1 和 Transaction2 全部 Rollback（死锁问题并没有解决，如果不幸，下次执行还会重现）。

如果每个 Transaction 都是 Update 数万，数十万的记录（我们的业务就是），那事务的回滚代价就非常高，还会引起数据库的性能波动。
解决办法很多，比如先查询出数据后再做逐条做写操作, 或者写操作加上一个 limit 限制每次的更新次数，同时避免两个 Transaction 并发执行等等。最终在调整了 Checker 的运行周期后选择了逐条更新的方案，因为业务对于时间上要求并不高，更新不及时并不会引起业务上的错误。

经过以上优化后，压测表明整个平台 3 倍峰值流量下，数据库 CPU 利用率 10% 以下，load5 以下，95% 的远程调用只有一次数据库的 Insert 操作，远程接口 TP999 在 20ms 内。

第二类问题是因为代码编写不当，引发 JVM 假死和 CPU 100%。

出于减少远程接口同步逻辑的需要，研发同学将大部分操作改为异步方式，比如邮件的推荐商品服务。因为邮件发送任务在生产平台到发送平台间流转需要一定的时间，将推荐商品服务异步化后，生产邮件发送任务的同步逻辑会减少，远程接口调用或 MQ 消息消费线程可以更早返回，对推荐接口的性能波动容忍度也会变高，只需要保证在发送平台渲染邮件模板前能够拿到推荐商品的数据即可。

异步改造时，研发同学使用了线程池的无界队列，并因为一个低级 BUG 导致上线后无界队列的消费线程只有 5 个，生产和消费的速率严重不匹配，导致了短时间内 JVM 内存占用过高，JVM 频繁 GC，JVM 频繁处于“stop the world”阶段，呈现出“假死”状态，最终再次影响到远程接口的调用和 MQ 消息的消费。这次的经验说明，实例宕机或许并不是最难处理的，更难处理的是实例处于可以提供服务，但是没有服务能力的状态。

我们的解决方案是使用有界队列，防止超长队列的产生。设置队列的拒绝策略，队列无空闲位置时，放弃入队操作。此时会导致部分邮件缺少推荐商品模块，可视作推荐商品模块的处理能力达到上限后的一种降级方式。

Redis 队列中元素的大小大于 10K 时，入队和出队的效率会严重下降，出于这这个原因，Redis 队列中只存放有邮件发送任务的原始数据，渲染工作是在发送节点上完成的。发送高峰期时，发送平台的 CPU 利用率整体在 80% 甚至 90% 以上，发送能力无法再提升。经过一系列排查后发现 CPU 利用率较高的源头来自于 Handlebars 模板渲染模块。

抽样查看部分线上机器的线程占用率时发现渲染线程大部分时间一直在做邮件模板的语法解析，参考相应文档后发现语法解析是模板渲染中最耗时的流程，为了提高效率无论是 Velocity 还是 Handlbars 都会对模板语法解析的结果做缓存，下次渲染时直接使用解析结果渲染。但缓存是基于 VelocityEngine 或 Handlebar 实例的，如果 JVM 中存在多个 VelocityEngine 或 Handlebar 实例，缓存就无法有效利用，结果是每次渲染模板时都要做语法解析，如果并发解析的线程达到数十、数百个的话，就会引起实例的 CPU 100%。

解决方案：

• 保证全局只有一个 Handlebar 实例，方便共享缓存结果。
• 容器启动时，渲染线程依次启动并等待一段时间在启动下一个渲染线程，避免并发启动多个线程时再次出现并发解析模板的情况。

除去以上问题的解决，上线后研发团队还做了几次全流程的优化，优化包括黑名单、退订数据缓存化，Redis 队列 Push 方式异步化、批量化，发送平台的拉取合并、邮件模板本地化等。

优化后平台的应用架构如下：

容灾方案

容灾方案中，优先考虑的就是多网络运营商覆盖的问题，防止某一网络运营商网络故障影响邮件发送的能力。目前的方案是单一机房配置单一网络运营商的出口 IP 及反解析域名，每个机房部署相应的生产平台，Redis 队列和发送平台，彼此之间相互独立运行，底层使用同一个数据库，生产平台提供的远程接口为同一个别名服务，MQ 消息也是消费的同一个 Topic 下的内容，多个 Redis 之间存在少量数据的同步，比如去重数据。整体架构如下：

我们将紧急情况分为内部接口、服务故障和外部服务故障。针对内部故障，比如：

• Redis 集群故障。如果是单分片故障，Redis 集群提供了主从分片，可以通过切换分片的方式解决。如果是集群整体故障，可以启用备用 Redis 集群，在这里不存在集群数据为空的问题，因为生产平台有 Checker 存在，如果切换集群，Checker 可以感知到 Redis 队列数据量不够，会重新将待发送的邮件任务 Push 到 Redis 队列中。

针对外部故障，比如：

• 机房出口网络故障。可以停止故障机房的发送平台，因数据库共享，数据入库后对端机房的 Checker 会将数据重新 Push 到对端机房的 Redis 队列中，从对端机房发送邮件任务。这里还有一种方案是修改故障机房的 Redis 集群配置，故障机房的生产平台生成邮件发送任务后直接将数据 Push 到对端机房的 Redis 集群中，省略 Checker 扫描的这一步，会大大减少数据库的读压力。
• 邮件服务提供商对部分出口 IP 降频。发送节点上内置了降频处理措施，可以解决该问题。
• 邮件服务商屏蔽部分出口 IP。通过自研的配置推送与服务监控框架，可用管理平台将被屏蔽的 IP 地址推送到发送平台上，发送平台通过比对如果发现自身已被屏蔽，将不再从 Redis 队列中 Pull 相应的邮件发送任务。

总结

EDM 平台上层对接了精准营销平台和生产邮件业务，如何用一套通用的解决方案解决两个业务的不同需求是建设该平台的难点，需要在两种业务形态间找到共性并满足各自业务对及时性，发送量方面的要求。尤其是生产邮件业务，对发送的及时性，稳定性的要求都较高，非常容易引起上层业务团队的关注。在做方案时需要更多的关注到架构本身对性能、容灾、业务和研发同学的友好性，架构越容易让人接受，更简单的解决现有问题，才有可能在以后的发展中不断往好的方向进化，容纳更多复杂的业务需求，支持业务的长久发展。

作者介绍

刘锟洋，独立博主，系统架构师。就职于京东成都研究院，做过 A/B Test，精准营销平台，会员营销平台。公司内部开源小组发起人，内部开源过多个开源项目，对性能全链路优化和分布式服平台有浓厚兴趣。

感谢郭蕾对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。