1.主要工作內(nèi)容
原有用戶觸達(dá)邏輯分散在各個(gè)系統(tǒng)，比較雜亂，實(shí)現(xiàn)各種觸達(dá)消息的統(tǒng)一發(fā)送、記錄、控制，對(duì)上游業(yè)務(wù)屏蔽消息發(fā)送的復(fù)雜性，將用戶觸達(dá)邏輯封裝獨(dú)立出來(lái)，建立保險(xiǎn)的消息觸達(dá)平臺(tái)。觸達(dá)渠道包括：短信、PUSH、在線客服、微信公眾號(hào)、人工。新平臺(tái)可以靈活支持不同的產(chǎn)品，觸達(dá)策略可跟蹤、可追溯、效果可驗(yàn)證，可配置化。根據(jù)保單不同的生命周期階段及系統(tǒng)的現(xiàn)狀，觸達(dá)功能的實(shí)現(xiàn)可分為在線任務(wù)和離線任務(wù)：
●在線任務(wù)：訂單狀態(tài)變更后之后的觸達(dá)根據(jù)時(shí)效性要求，通過(guò)消費(fèi)mysql-binlog/kafka消息來(lái)捕獲投保成功事件，根據(jù)配置的觸達(dá)策略進(jìn)行觸達(dá)；
●離線任務(wù)：部分場(chǎng)景根據(jù)配置的策略每天定時(shí)生成觸達(dá)批次、觸達(dá)任務(wù)和觸達(dá)明細(xì)，根據(jù)具體的觸達(dá)策略來(lái)進(jìn)行觸達(dá)
2. 工作思路
2.1 業(yè)務(wù)設(shè)計(jì)
由于在之前公司接觸過(guò)消息系統(tǒng)的設(shè)計(jì)、開(kāi)發(fā)與維護(hù)，所以參照以往的規(guī)則設(shè)計(jì)消息觸達(dá)系統(tǒng)，總體思路不變，只是為了數(shù)據(jù)統(tǒng)計(jì)的方便拆分更細(xì)，同時(shí)為了支持離線任務(wù)的執(zhí)行，引入了批次等設(shè)計(jì)。
2.1.1數(shù)據(jù)庫(kù)設(shè)計(jì)
2.2 技術(shù)設(shè)計(jì)
對(duì)于實(shí)時(shí)的在線任務(wù)，我們開(kāi)啟相關(guān)數(shù)據(jù)庫(kù)的Binlog功能，使用kafka實(shí)時(shí)監(jiān)聽(tīng)數(shù)據(jù)表字段的新增和更新，消費(fèi)者消費(fèi)消息完成后續(xù)的觸達(dá)任務(wù)。對(duì)于離線任務(wù)我們使用多線程的離線任務(wù)定期掃描明細(xì)表，創(chuàng)建新的任務(wù)批次進(jìn)行發(fā)送。
這里的幾個(gè)關(guān)鍵技術(shù)就是MySql的Binlog，Kafka的接入，離線任務(wù)的編寫。
3. 知識(shí)點(diǎn)整理
3.1 Binlog
● binlog是記錄所有數(shù)據(jù)庫(kù)表結(jié)構(gòu)變更（例如CREATE、ALTER TABLE…）以及表數(shù)據(jù)修改（INSERT、UPDATE、DELETE…）的二進(jìn)制日志。
● binlog不會(huì)記錄SELECT和SHOW這類操作，因?yàn)檫@類操作對(duì)數(shù)據(jù)本身并沒(méi)有修改，但你可以通過(guò)查詢通用日志來(lái)查看MySQL執(zhí)行過(guò)的所有語(yǔ)句。
● 如果update操作沒(méi)有造成數(shù)據(jù)變化，也是會(huì)記入binlog。
這個(gè)二進(jìn)制日志包括兩類文件：
索引文件（文件名后綴為.index）用于記錄哪些日志文件正在被使用。
日志文件（文件名后綴為.00000*）記錄數(shù)據(jù)庫(kù)所有的DDL和DML(除了數(shù)據(jù)查詢語(yǔ)句)語(yǔ)句事件。
Binlog的三個(gè)用途：
恢復(fù)：這里網(wǎng)上有大把的文章指導(dǎo)你，如何利用binlog日志恢復(fù)數(shù)據(jù)庫(kù)數(shù)據(jù)。
復(fù)制: 主從同步。主庫(kù)有一個(gè)log dump線程，將binlog傳給從庫(kù)從庫(kù)有兩個(gè)線程，一個(gè)I/O線程，一個(gè)SQL線程，I/O線程讀取主庫(kù)傳過(guò)來(lái)的binlog內(nèi)容并寫入到relay log,SQL線程從relay log里面讀取內(nèi)容，寫入從庫(kù)的數(shù)據(jù)庫(kù)。
審計(jì)：用戶可以通過(guò)二進(jìn)制日志中的信息來(lái)進(jìn)行審計(jì)，判斷是否有對(duì)數(shù)據(jù)庫(kù)進(jìn)行注入攻擊。
3.2 Kafka
3.2.1 Kafka的特性
高吞吐量、低延遲：kafka每秒可以處理幾十萬(wàn)條消息，它的延遲最低只有幾毫秒，每個(gè)topic可以分多個(gè)partition, consumer group 對(duì)partition進(jìn)行consume操作
可擴(kuò)展性：kafka集群支持熱擴(kuò)展
持久性、可靠性：消息被持久化到本地磁盤，并且支持?jǐn)?shù)據(jù)備份防止數(shù)據(jù)丟失
容錯(cuò)性：允許集群中節(jié)點(diǎn)失?。ㄈ舾北緮?shù)量為n,則允許n-1個(gè)節(jié)點(diǎn)失?。?/p>
高并發(fā)：支持?jǐn)?shù)千個(gè)客戶端同時(shí)讀寫
3.2.2 Kafka的使用場(chǎng)景
日志收集：一個(gè)公司可以用Kafka可以收集各種服務(wù)的log，通過(guò)kafka以統(tǒng)一接口服務(wù)的方式開(kāi)放給各種consumer，例如hadoop、Hbase、Solr等。
消息系統(tǒng)：解耦和生產(chǎn)者和消費(fèi)者、緩存消息等。
用戶活動(dòng)跟蹤：Kafka經(jīng)常被用來(lái)記錄web用戶或者app用戶的各種活動(dòng)，如瀏覽網(wǎng)頁(yè)、搜索、點(diǎn)擊等活動(dòng)，這些活動(dòng)信息被各個(gè)服務(wù)器發(fā)布到kafka的topic中，然后訂閱者通過(guò)訂閱這些topic來(lái)做實(shí)時(shí)的監(jiān)控分析，或者裝載到hadoop、數(shù)據(jù)倉(cāng)庫(kù)中做離線分析和挖掘。
運(yùn)營(yíng)指標(biāo)：Kafka也經(jīng)常用來(lái)記錄運(yùn)營(yíng)監(jiān)控?cái)?shù)據(jù)。包括收集各種分布式應(yīng)用的數(shù)據(jù)，生產(chǎn)各種操作的集中反饋，比如報(bào)警和報(bào)告。
流式處理：比如spark streaming和storm
3.2.3 Kafka的結(jié)構(gòu)
Producer：Producer即生產(chǎn)者，消息的產(chǎn)生者，是消息的入口。
kafka cluster：
-Broker：Broker是kafka實(shí)例，每個(gè)服務(wù)器上有一個(gè)或多個(gè)kafka的實(shí)例，我們姑且認(rèn)為每個(gè)broker對(duì)應(yīng)一臺(tái)服務(wù)器。每個(gè)kafka集群內(nèi)的broker都有一個(gè)不重復(fù)的編號(hào)，如圖中的broker-0、broker-1等……
-Topic：消息的主題，可以理解為消息的分類，kafka的數(shù)據(jù)就保存在topic。在每個(gè)broker上都可以創(chuàng)建多個(gè)topic。
-Partition：Topic的分區(qū)，每個(gè)topic可以有多個(gè)分區(qū)，分區(qū)的作用是做負(fù)載，提高kafka的吞吐量。同一個(gè)topic在不同的分區(qū)的數(shù)據(jù)是不重復(fù)的，partition的表現(xiàn)形式就是一個(gè)一個(gè)的文件夾！
-Replication:每一個(gè)分區(qū)都有多個(gè)副本，副本的作用是做備胎。當(dāng)主分區(qū)（Leader）故障的時(shí)候會(huì)選擇一個(gè)備胎（Follower）上位，成為L(zhǎng)eader。在kafka中默認(rèn)副本的最大數(shù)量是10個(gè)，且副本的數(shù)量不能大于Broker的數(shù)量，follower和leader絕對(duì)是在不同的機(jī)器，同一機(jī)器對(duì)同一個(gè)分區(qū)也只可能存放一個(gè)副本（包括自己）。
-Message：每一條發(fā)送的消息主體。
Consumer：消費(fèi)者，即消息的消費(fèi)方，是消息的出口。
Consumer Group：我們可以將多個(gè)消費(fèi)組組成一個(gè)消費(fèi)者組，在kafka的設(shè)計(jì)中同一個(gè)分區(qū)的數(shù)據(jù)只能被消費(fèi)者組中的某一個(gè)消費(fèi)者消費(fèi)。同一個(gè)消費(fèi)者組的消費(fèi)者可以消費(fèi)同一個(gè)topic的不同分區(qū)的數(shù)據(jù)，這也是為了提高kafka的吞吐量！
Zookeeper：kafka集群依賴zookeeper來(lái)保存集群的的元信息，來(lái)保證系統(tǒng)的可用性。
3.2.4 Kafka分區(qū)和確認(rèn)機(jī)制
熟悉負(fù)載均衡的朋友應(yīng)該知道，當(dāng)我們向某個(gè)服務(wù)器發(fā)送請(qǐng)求的時(shí)候，服務(wù)端可能會(huì)對(duì)請(qǐng)求做一個(gè)負(fù)載，將流量分發(fā)到不同的服務(wù)器，那在kafka中，如果某個(gè)topic有多個(gè)partition，producer又怎么知道該將數(shù)據(jù)發(fā)往哪個(gè)partition呢？kafka中有幾個(gè)原則：
1、partition在寫入的時(shí)候可以指定需要寫入的partition，如果有指定，則寫入對(duì)應(yīng)的partition。
2、如果沒(méi)有指定partition，但是設(shè)置了數(shù)據(jù)的key，則會(huì)根據(jù)key的值hash出一個(gè)partition。
3、如果既沒(méi)指定partition，又沒(méi)有設(shè)置key，則會(huì)輪詢選出一個(gè)partition。
保證消息不丟失是一個(gè)消息隊(duì)列中間件的基本保證，那producer在向kafka寫入消息的時(shí)候，怎么保證消息不丟失呢？其實(shí)上面的寫入流程圖中有描述出來(lái)，那就是通過(guò)ACK應(yīng)答機(jī)制！在生產(chǎn)者向隊(duì)列寫入數(shù)據(jù)的時(shí)候可以設(shè)置參數(shù)來(lái)確定是否確認(rèn)kafka接收到數(shù)據(jù)，這個(gè)參數(shù)可設(shè)置的值為0、1、all。
0代表producer往集群發(fā)送數(shù)據(jù)不需要等到集群的返回，不確保消息發(fā)送成功。安全性最低但是效率最高。
1代表producer往集群發(fā)送數(shù)據(jù)只要leader應(yīng)答就可以發(fā)送下一條，只確保leader發(fā)送成功。
all代表producer往集群發(fā)送數(shù)據(jù)需要所有的follower都完成從leader的同步才會(huì)發(fā)送下一條，確保leader發(fā)送成功和所有的副本都完成備份。安全性最高，但是效率最低。
3.4 離線任務(wù)
這里使用的是Linux的crontab。
