1.主要工作内容
原有用户触达逻辑分散在各个系统，比较杂乱，实现各种触达消息的统一发送、记录、控制，对上游业务屏蔽消息发送的复杂性，将用户触达逻辑封装独立出来，建立保险的消息触达平台。触达渠道包括：短信、PUSH、在线客服、微信公众号、人工。新平台可以灵活支持不同的产品，触达策略可跟踪、可追溯、效果可验证，可配置化。根据保单不同的生命周期阶段及系统的现状，触达功能的实现可分为在线任务和离线任务：
●在线任务：订单状态变更后之后的触达根据时效性要求，通过消费mysql-binlog/kafka消息来捕获投保成功事件，根据配置的触达策略进行触达；
●离线任务：部分场景根据配置的策略每天定时生成触达批次、触达任务和触达明细，根据具体的触达策略来进行触达
2. 工作思路
2.1 业务设计
由于在之前公司接触过消息系统的设计、开发与维护，所以参照以往的规则设计消息触达系统，总体思路不变，只是为了数据统计的方便拆分更细，同时为了支持离线任务的执行，引入了批次等设计。
2.1.1数据库设计
2.2 技术设计
对于实时的在线任务，我们开启相关数据库的Binlog功能，使用kafka实时监听数据表字段的新增和更新，消费者消费消息完成后续的触达任务。对于离线任务我们使用多线程的离线任务定期扫描明细表，创建新的任务批次进行发送。
这里的几个关键技术就是MySql的Binlog，Kafka的接入，离线任务的编写。
3. 知识点整理
3.1 Binlog
● binlog是记录所有数据库表结构变更（例如CREATE、ALTER TABLE…）以及表数据修改（INSERT、UPDATE、DELETE…）的二进制日志。
● binlog不会记录SELECT和SHOW这类操作，因为这类操作对数据本身并没有修改，但你可以通过查询通用日志来查看MySQL执行过的所有语句。
● 如果update操作没有造成数据变化，也是会记入binlog。
这个二进制日志包括两类文件：
索引文件（文件名后缀为.index）用于记录哪些日志文件正在被使用。
日志文件（文件名后缀为.00000*）记录数据库所有的DDL和DML(除了数据查询语句)语句事件。
Binlog的三个用途：
恢复：这里网上有大把的文章指导你，如何利用binlog日志恢复数据库数据。
复制: 主从同步。主库有一个log dump线程，将binlog传给从库从库有两个线程，一个I/O线程，一个SQL线程，I/O线程读取主库传过来的binlog内容并写入到relay log,SQL线程从relay log里面读取内容，写入从库的数据库。
审计：用户可以通过二进制日志中的信息来进行审计，判断是否有对数据库进行注入攻击。
3.2 Kafka
3.2.1 Kafka的特性
高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒，每个topic可以分多个partition, consumer group 对partition进行consume操作
可扩展性：kafka集群支持热扩展
持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失
容错性：允许集群中节点失败（若副本数量为n,则允许n-1个节点失败）
高并发：支持数千个客户端同时读写
3.2.2 Kafka的使用场景
日志收集：一个公司可以用Kafka可以收集各种服务的log，通过kafka以统一接口服务的方式开放给各种consumer，例如hadoop、Hbase、Solr等。
消息系统：解耦和生产者和消费者、缓存消息等。
用户活动跟踪：Kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过订阅这些topic来做实时的监控分析，或者装载到hadoop、数据仓库中做离线分析和挖掘。
运营指标：Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集中反馈，比如报警和报告。
流式处理：比如spark streaming和storm
3.2.3 Kafka的结构
Producer：Producer即生产者，消息的产生者，是消息的入口。
kafka cluster：
-Broker：Broker是kafka实例，每个服务器上有一个或多个kafka的实例，我们姑且认为每个broker对应一台服务器。每个kafka集群内的broker都有一个不重复的编号，如图中的broker-0、broker-1等……
-Topic：消息的主题，可以理解为消息的分类，kafka的数据就保存在topic。在每个broker上都可以创建多个topic。
-Partition：Topic的分区，每个topic可以有多个分区，分区的作用是做负载，提高kafka的吞吐量。同一个topic在不同的分区的数据是不重复的，partition的表现形式就是一个一个的文件夹！
-Replication:每一个分区都有多个副本，副本的作用是做备胎。当主分区（Leader）故障的时候会选择一个备胎（Follower）上位，成为Leader。在kafka中默认副本的最大数量是10个，且副本的数量不能大于Broker的数量，follower和leader绝对是在不同的机器，同一机器对同一个分区也只可能存放一个副本（包括自己）。
-Message：每一条发送的消息主体。
Consumer：消费者，即消息的消费方，是消息的出口。
Consumer Group：我们可以将多个消费组组成一个消费者组，在kafka的设计中同一个分区的数据只能被消费者组中的某一个消费者消费。同一个消费者组的消费者可以消费同一个topic的不同分区的数据，这也是为了提高kafka的吞吐量！
Zookeeper：kafka集群依赖zookeeper来保存集群的的元信息，来保证系统的可用性。
3.2.4 Kafka分区和确认机制
熟悉负载均衡的朋友应该知道，当我们向某个服务器发送请求的时候，服务端可能会对请求做一个负载，将流量分发到不同的服务器，那在kafka中，如果某个topic有多个partition，producer又怎么知道该将数据发往哪个partition呢？kafka中有几个原则：
1、partition在写入的时候可以指定需要写入的partition，如果有指定，则写入对应的partition。
2、如果没有指定partition，但是设置了数据的key，则会根据key的值hash出一个partition。
3、如果既没指定partition，又没有设置key，则会轮询选出一个partition。
保证消息不丢失是一个消息队列中间件的基本保证，那producer在向kafka写入消息的时候，怎么保证消息不丢失呢？其实上面的写入流程图中有描述出来，那就是通过ACK应答机制！在生产者向队列写入数据的时候可以设置参数来确定是否确认kafka接收到数据，这个参数可设置的值为0、1、all。
0代表producer往集群发送数据不需要等到集群的返回，不确保消息发送成功。安全性最低但是效率最高。
1代表producer往集群发送数据只要leader应答就可以发送下一条，只确保leader发送成功。
all代表producer往集群发送数据需要所有的follower都完成从leader的同步才会发送下一条，确保leader发送成功和所有的副本都完成备份。安全性最高，但是效率最低。
3.4 离线任务
这里使用的是Linux的crontab。
