簡介TiFlash
TiFlash是TiDB生态元件之一，專門解決OLAP場景。借助ClickHouse實作高效的列式計算。
介紹TiFlash架構
一開始，我個人以為他會是用binlog或其他方式把資料同步到TiFlash中，讀取資料有專門的接口，結果我的了解是錯誤的。
TiFlash通過Region的leader節點進行資料全量和增量同步。
增量同步是通過Raft Log異步複制，相當于MySQL的redo log同步。
我這裡就好奇，為啥不通過TiKV Follower 節點進行全量和增量的同步呢？
因為本身TiKV的資料就是強一緻的，并且TiKV的Leader節點還要承擔日常的讀寫壓力。
答： 這個是因為 Raft 協定實作的問題，目前都是以 leader 為準的。（來自神秘好友的解答）
目前TiKV應該不支援讀寫分離，如果把同步的節點改完TiKV的Follower節點，也不會影響資料的一緻性，并且能分擔Leader節點的壓力。
答： 這個的話，現在有 Follower Read 的功能，可以了解為讀寫分離，但是目前讀是強一緻性的，後續會允許異步讀取資料，也就是從 follower 上讀到一段時間之前的資料（來自神秘好友的解答）
核心特性
異步複制
TiFlash節點和TiKV節點進行複制同步期間，發生網絡延遲或者網絡抖動，不會影響到TiKV的運作。如果TiFlash節點當機了，也不會影響TiKV的運作。隻要TiKV的資料不丢失，TiFlash的資料就可以通過TiKV進行恢複。
簡單來說 你可以把TiFlash和TiKV的關系了解為MySQL的主從架構。MySQL主庫和從庫之間發生網絡抖動，或者MySQL從庫挂了。
并不會影響MySQL主庫的寫入和讀取（這裡說的是MySQL異步複制）。
智能選擇
TiDB可以自動選擇使用 TiFlash 列存或者TiKV行存。不需要通過其他接口通路TiFlash 。其實在這裡就實作了一個入口根據實際SQL選擇列存或者行存。
實驗環境：2張表一個是sbtest1、sbtest2有相同的資料。但sbtest1做了TiFlash同步，sbtest2還是保留TiKV存儲。
當sbtest1和sbtest2同時執行count的操作，二個表的執行計劃就不同了。
發現sbtest1表走了TiFlash列存儲，而sbtest2表則走了TiKV行存儲。
實驗2：sbtest1表執行不同的SQL，選擇行存或者列存就會發生轉變。
1154×448 120 KB
計算加速
通過列式引擎來提升TiDB讀取的效率的提升。
TiDB架構中本身就實作了計算下推，把計算任務推給了存儲引擎層也就是TiKV。
在新增列式存儲TiFlash環境中，TiFlash也承擔計算任務。
一緻性
TiFlash和TiKV一樣提供快照隔離的支援，并且保證讀取資料最新。這個一緻性是通過複制進度校驗來實作的。
每次接收到讀取請求，TiFlash 會向 Leader 發起進度校對。
隻有當進度確定至少所包含讀取請求時間戳所覆寫的資料之後才響應讀取。
部署TiFlash
TiDB版本大于TiDB3.1和TiDB4.0 。在tidb-ansible找到
[tiflash_servers] 填寫主機名和data目錄。
其他操作和部署TiDB無異，目前官方推薦使用TiUP進行部署，可以參考官方。
需要注意的是 不建議TiFlash和TiKV混合部署，不建議部署多執行個體。
個人建議TiFlash的配置比TiKV的配置要高一點。
因為畢竟TiFlash要跑OLAP業務，消耗資源可能會多一點。
使用TiFlash
TiFlash接入後，預設不會進行資料同步。可以針對表來進行TiFlash副本。
按照表建構TiFlash。
ALTER TABLE table_name SET TIFLASH REPLICA count
count表示副本數 ALTER TABLE table_name SET TIFLASH REPLICA 1
檢視表的同步進度
SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = '<db_name>' and TABLE_NAME = '<table_name>'
TiSpark可以直接讀取TiFlash中的資料。
優點
業務可以通過TiDB直接跑OLAP場景的SQL。
減少維護成本 資料庫（MySQL）到分析類型的資料庫（例如hadoop）之間的鍊路同步工具。減少分析資料庫（例如hadoop）的維護成本。
美中不足
資源隔離和資源排程
雖然TiFlash和TiKV中有資源隔離。TiFlash不會影響到TiKV的性能。
但我想說的是TiFlash裡的資源排程。
如果大量的消耗資源的SQL在TiFlash中運作，TiFlash會不會把整個系統的資源跑滿？導緻重要的其他SQL無法運作。
可以把一些慢的 不重要的SQL配置設定較少的系統資源。重要的SQL配置設定更多的系統資源。
總結 TiFlash還是一款非常不錯的元件，能夠解決一些痛點，滿足一些場景的需求，在官方持續維護下TiFlash的未來還是非常可期的。一開始，我個人以為他會是用binlog或其他方式把資料同步到TiFlash中，讀取資料有專門的接口，結果我的了解是錯誤的。