? ? ? ? 因為作業(yè)系統(tǒng)，難免會遇到這樣一些問題，就是報表业扒，各種緯度查詢，而我們項目又不是基于大數(shù)據(jù)框架來做的舒萎，所以在滿足多維度方面程储，以及實時性要求方面就稍顯遜色
如果基于現(xiàn)有系統(tǒng)業(yè)務(wù)，讓你去實現(xiàn)一個統(tǒng)計類報表臂寝，你的方案章鲤？
第一種方案，各種表數(shù)據(jù)關(guān)聯(lián)交煞，然后滿足業(yè)務(wù)要求咏窿。問題來了，我們有些表用了分表素征，有些表又是跨庫了集嵌，怎么辦？
方案二御毅，我們建一張大表根欧，然后把關(guān)聯(lián)表的數(shù)據(jù)都往這張大表里塞，然后去查詢端蛆。這里的問題就是凤粗，這張表很快就會被撐爆掉，直到最后查不了今豆。后來我們引入es嫌拣，但是前提還是基于這張大表，比如我們的庫存流水記錄
現(xiàn)有實現(xiàn)呆躲，我們通過定時任務(wù)撈取增量數(shù)據(jù)然后往es推送异逐，然后查詢直接通過es查詢，解決了多維度的查詢問題插掂。這里我們發(fā)現(xiàn)一個問題灰瞻，那就是報表的實時性。如果現(xiàn)場業(yè)務(wù)允許你的延遲辅甥，那么你可以這么做酝润。
為了低延時，我們引入binlog方案
binlog方案是基于目前數(shù)據(jù)庫的binlog璃弄，我們直接讀取過來要销，然后直接推送es。
這里需要考慮以下問題谢揪？
如何獲取binlog蕉陋？binlog和作業(yè)系統(tǒng)如何打通捐凭？binlog的解析拨扶？binlog的批量推送es凳鬓，es能扛多大并發(fā)？
如何獲取binlog,這里我們是主從備份的方案中獲取靈感患民，再加一個備庫缩举，接到主庫上。接到之后匹颤，我們直接拋到kafka仅孩，這里這樣做的目地就是binlog的量非常大，也是考慮到kafka出色的并發(fā)能力印蓖，目前是整庫遷移方案辽慕，所以有個問題就是如果這個庫的表數(shù)量很大，那么我們便利我們所需要的表赦肃，也很耗時溅蛉，這就違背了我們的初衷。后期需要迭代表的遷移方案他宛。
發(fā)布=訂閱船侧，我們首先要知道的就是，binlog本身就是有順序的厅各，然后通過kafka一批過來镜撩，而我們的作業(yè)系統(tǒng)又是集群架構(gòu)，這就會因為并發(fā)導致一系列問題队塘。比如袁梗，因為最新操作的binlog，卻因為作業(yè)系統(tǒng)并發(fā)最先執(zhí)行憔古，而早期的binlog卻最后執(zhí)行遮怜，這就造成了老數(shù)據(jù)覆蓋新數(shù)據(jù)。這是一個很嚴重的問題投放。所以我們就做了這樣這個規(guī)定奈泪，每張表，我們使用一個主題灸芳，任何時刻只允許一臺機器消費涝桅。
所以建立好這樣的規(guī)則之后，我們就拿到了這張表的binlog烙样，并且一定是順序拿到的冯遂。接到數(shù)據(jù)操作之后，開始解析谒获，解析就是把binlog轉(zhuǎn)化為我們的要操作的數(shù)據(jù)蛤肌。
binlog結(jié)構(gòu)壁却，每一步數(shù)據(jù)表的操作，都會有一條binlog裸准，分為兩部分展东，操作頭，操作數(shù)炒俱。操作頭里包含了我們的表名盐肃，以及關(guān)鍵字，比如insert,update等权悟。操作數(shù)分為砸王，操作前和操作后的數(shù)據(jù)兩部分。
一批解析完峦阁，然后逐條推送es谦铃，有必要這樣做？
因為我們每拿到一批榔昔，已經(jīng)是有先后順序驹闰，那我們只要拿到這一批中，操作時間最新的那一條不就可以么件豌，這樣前面的全部省略疮方，推送es的并發(fā)也就會降下來
目前該方案還在摸索階段，成熟以后茧彤，會再做一次分享
