前置概念

無并發(fā)的解決方案

一些小型項目，或極少有并發(fā)的項目，這些策略在無并發(fā)情況下，不會有什么問題。

• 讀數(shù)據(jù)策略：有緩存則讀緩存，然后接口返回。沒有緩存，查詢出數(shù)據(jù)，載入緩存，然后接口返回。
• 寫數(shù)據(jù)策略：數(shù)據(jù)發(fā)生了變動，先刪除緩存，再更新數(shù)據(jù)，等下次讀取的時候載入緩存，或一步到位更新數(shù)據(jù)后直接更新緩存。
• 以上這種方案，有個高大上的名字，叫Cache Aside Pattern。

并發(fā)情況下的分布式緩存一致性問題

• 并發(fā)：無論是Java的多線程，還是PHP的多進程（默認的單線程），用戶量或請求量一上來，就可能有并發(fā)問題，正確的應對并發(fā)，保證數(shù)據(jù)不出錯，顯得尤為重要。
• 緩存：任何組件（不僅是Redis與MySQL），只要源數(shù)據(jù)并非一成不變，且有緩存機制，就會有一致性的問題。
• 單體架構：強一致性若在單機上，并不是一個問題，例如MySQL的非冗余字段的變動，關聯(lián)另一個冗余它的字段，這等強一致性的緩存問題，在一個事務里就能維護。
• 分布式：一致性的難點主要在分布式環(huán)境下，例如MySQL主從，就添加了bin log與redo log的兩階段提交策略來防止主從數(shù)據(jù)不一致。針對MySQL與Redis，可以理解成分布式系統(tǒng)，如果沒有并發(fā)，則按照文章開頭的方案正常處理，如果有并發(fā)，就需要一些策略保證讀取的是最新的緩存數(shù)據(jù)，因為目前沒有一些機制，讓MySQL和Redis共同在一個事務內，能一起提交或者回滾，保持強一致。
• 注意：緩存一致性問題是個概率問題，不是一定出現(xiàn)或一定不出現(xiàn)，并發(fā)情況下，如果不加鎖，MySQL與Redis讀寫時序是不可控的。

并發(fā)與并行，同步與異步

經(jīng)常聽到并發(fā)，可真的理解這個概念嗎？

• 并發(fā)：多過分任務同時進行，但這些任務是交替執(zhí)行（分配不同的時間片，進程或者線程的上下文切換），好比排n個隊去1個窗口辦事。
• 并行：多個任務在同一時刻同時執(zhí)行，通常需要多個或多核處理器，好比排n個隊去n個窗口辦事。
• 同步：上個任務執(zhí)行完畢后再執(zhí)行下一個任務，所以同步?jīng)]有并發(fā)或并行的概念。
• 異步：下一個任務不用等待上個任務執(zhí)行完。

分布式必知的CAP定理

• 一致性（Consistency）：每個節(jié)點的數(shù)據(jù)需要與源數(shù)據(jù)保持一致，這里往往指的是強一致性。
• 可用性（Availability）：這指的是系統(tǒng)能夠在任何時刻都對外提供服務，所謂的穩(wěn)定高可用。
• 分區(qū)容錯性（Partition Tolerance）：分布式系統(tǒng)下，某節(jié)點掛掉，還能夠對外提供服務的能力。

為什么CAP只能3選2

• CP舍去A：意味著分布式環(huán)境保證強一致，一個數(shù)據(jù)的變動必須及時通知所有的節(jié)點，每個節(jié)點為了保證強一致，不得不加鎖，此時一個并發(fā)過來請求上鎖的數(shù)據(jù)，不是失敗就是被阻塞，高可用就達不到。常見于銀行，金融，支付系統(tǒng)。

• AP舍去C：意味著分布式系統(tǒng)舍棄掉一致性，一個數(shù)據(jù)的變動必須不一定會通知所有的節(jié)點，每個節(jié)點也不一定加鎖，所以就不會出現(xiàn)阻塞或者失敗的情況。常見的DNS、CDN系統(tǒng)就是這樣，修改源數(shù)據(jù)不會立即生效，盡管短時間讀取還是老數(shù)據(jù)，但是它不會因為你修改就加鎖或者阻塞，它還讓你用。

• CA舍去P：意味著分布式系統(tǒng)下不具有分區(qū)容錯性，但是是個分布式就有小概率會出問題，盡管很低，想杜絕分區(qū)容錯性，只能是單體架構。常見于單機系統(tǒng)。

• 架構的設計是根據(jù)當前業(yè)務特性權衡而來的結果。一個兜底的策略，要看當前業(yè)務不能接受哪些缺點，而不是看有哪些優(yōu)點，然后去一步步演進，改善它。

ACID中的C與CAP中的C

不是一個概念。

• ACID中的C：是事務內的數(shù)據(jù)，從一個合法狀態(tài)轉換到另一個合法的狀態(tài)（這里的合法，指符合業(yè)務，符合事務的變化規(guī)律，A轉賬B 50元，雙方余額加減的過程，數(shù)只能是50，不會是60）。
• CAP中的C，緩存的數(shù)據(jù)需要與源數(shù)據(jù)保持一致。

分布式必知的BASE理論

可以理解為CAP的寬松方案，通過犧牲數(shù)據(jù)的強一致性，來獲得高可用性。
BASE理論最經(jīng)典的場景，就是支付回調，支付狀態(tài)允許存在幾秒鐘的延遲，而不是支付后實時獲取。

• 基本可用性（Basic Availability）：允許系統(tǒng)中的某些部分出現(xiàn)故障，保證核心功能的正常運行。常見的負載均衡、服務降級、限流等方式。

• 軟狀態(tài)（Soft state）：允許數(shù)據(jù)存在中間狀態(tài)，或者說是游離態(tài)，允許數(shù)據(jù)在某些時刻不一致，但是最終達到一致性的狀態(tài)。支付回調前支付狀態(tài)的場景。

• 最終一致性（Eventually Consistency）：系統(tǒng)中的數(shù)據(jù)在經(jīng)過一段時間后，最終會達到一致的狀態(tài)。不需要強制性的實時保持一致，只需要最后保持一致性。支付回調后支付狀態(tài)的場景。

強一致性、弱一致性、順序一致性、線性一致性、因果一致性、最終一致性

• 強一致性：等價嚴格、原子、線性一致，所有節(jié)點操作順序都與全局時鐘下的幾乎一致，需加鎖，常見于金融、銀行場景。
• 弱一致性：能容忍數(shù)據(jù)短時間內不一致，或能容忍部分數(shù)據(jù)不一致。常見于CDN和DNS場景。
• 順序一致性：強一致，在不同的節(jié)點上保持一致的操作執(zhí)行順序，需要加鎖。常見于分布式隊列場景。
• 最終一致性：弱一致，最終一致性就屬于弱一致性，概念相似。常見于支付回調，離線下載，異步同步大文件的場景。
• 線性一致性：強一致，強一致性、嚴格一致性、原子一致性一回事，同上。
• 因果一致性：弱一致，屬于事件觸發(fā)類型，因為觸發(fā)，果為執(zhí)行，常見于MySQL異步主從（弱一致）、分布式評論系統(tǒng)。

詳解順序一致性：
假設有兩個節(jié)點，在一個分布式系統(tǒng)中執(zhí)行寫操作。如果 節(jié)點A 在時間點 1 執(zhí)行了寫操作 W1，然后 節(jié)點B 在時間點 2 執(zhí)行了寫操作 W2。那么順序一致性要求在分布式系統(tǒng)的其它節(jié)點上，讀取數(shù)據(jù)的時候：
應該先看到 W1 的效果，然后才能看到 W2 的效果，而不是先看到W2再看到W1的結果。
并且保證，再同一時間，不能出現(xiàn)節(jié)點1看到 W1 的效果，節(jié)點2看到 W2 的效果。

全局時鐘

分布式下的全局時鐘，指的是分布式的每個節(jié)點，都有著一致的時間基準，就像共用一個時鐘一樣，讓每個節(jié)點在一致的時間線上處理各自的數(shù)據(jù)，這個非常重要。

實操

增數(shù)據(jù)后，保證Redis讀取的是最新的數(shù)據(jù)

不存在一致性問題。
請求A新增數(shù)據(jù)時，有并發(fā)讀請求B，此時B是查不到緩存的的，就會查詢MySQL。
如果B查到數(shù)據(jù)就載入緩存。
如果B沒查到數(shù)據(jù)，就等后面的請求查詢到數(shù)據(jù)后再載入緩存。
無論B能否查詢到緩存，都不影響A的插入，或C的讀取，因此不影響數(shù)據(jù)一致性。

刪數(shù)據(jù)后，保證Redis讀取的是最新的數(shù)據(jù)

1. 情況1：不存在一致性問題，緩存中沒有這塊數(shù)據(jù)，刪除MySQL數(shù)據(jù)后沒有其它副本。
2. 情況2：存在一致性問題，緩存中有這塊數(shù)據(jù)，此時就有2種策略：

• 先刪除緩存再刪除數(shù)據(jù)：
  不行。如果請求A緩存刪除成功，此時一個過來一個讀請求B，會查詢到即將要刪掉的MySQL數(shù)據(jù)，并將其重新載入緩存，請求A執(zhí)行MySQL delete后，會造成MySQL無數(shù)據(jù)，Redis有數(shù)據(jù)的情況，緩存不一致。

• 先刪除數(shù)據(jù)再刪除緩存：
  也有問題。請求A發(fā)現(xiàn)緩存數(shù)據(jù)不存在，讀取了MySQL數(shù)據(jù)，此時請求B刪除MySQL數(shù)據(jù)，接著請求B刪除緩存數(shù)據(jù)，請求A將老數(shù)據(jù)寫入緩存。此時數(shù)據(jù)庫里沒數(shù)據(jù)，Redis里有數(shù)據(jù)，緩存不一致。
  并發(fā)情況下，沒辦法控制執(zhí)行順序問題，所以這就是個概率問題。

改數(shù)據(jù)后，保證Redis讀取的是最新的數(shù)據(jù)

1. 情況1：不存在一致性問題，緩存中沒有這塊數(shù)據(jù)，更新MySQL數(shù)據(jù)后沒有其它副本。
2. 情況2：存在一致性問題，緩存中有這塊數(shù)據(jù)，此時就有5種策略：

• 先更新數(shù)據(jù)再更新緩存：
  不行。v初始值為0，更新請求A，將值改為1，此時過來更新請求B，將值改為2，確定MySQL最終的值是2。但是受redis網(wǎng)絡連接卡頓等影響，更新請求B先將緩存中的v值改為2，更新請求A再將緩存中的值改為1。此時MySQL的值為2，緩存中的值為1，緩存不一致。

• 先更新緩存再更新數(shù)據(jù)：
  不行。v初始值為0，更新請求A修改緩存數(shù)據(jù)，v值改為1，然后更新MySQL，此時MySQL更新失敗,或事務回滾，雖然后續(xù)的讀緩存的是新數(shù)據(jù)，數(shù)據(jù)庫的是老數(shù)據(jù)，但這種臟數(shù)據(jù)再某些場景下是不允許發(fā)生的，緩存不一致。如果非要使用，可以再更新完緩存后，通過消息中間件異步更新數(shù)據(jù)庫。

• 先更新數(shù)據(jù)再刪除緩存：
  不行。v初始值為0，更新請求A將v值改為1，更新請求B將v值改為2，更新請求A刪除緩存，更新請求B刪除緩存，然后A、B都將值寫入MySQL。此時查詢請求C過來，獲取的可以使最新的數(shù)據(jù)并載入緩存。
  另一種情況：
  v初始值為0，更新請求A將v值改為1，更新請求B將v值改為2，更新請求A刪除緩存，更新請求B刪除緩存，然后更新請求A將1寫入MySQL，此時查詢請求C過來，沒有緩存，查MySQL發(fā)現(xiàn)是1，載入緩存。更新請求B將MySQL值改為2，此時緩存不一致。
  另一種情況：
  v初始值為0，讀請求X查詢不到緩存的數(shù)據(jù)，于是讀MySQL，獲取值為0，此時過來一個更新請求Y，將MySQL中的0改為1，然后刪除緩存，請求X又將老數(shù)據(jù)0載入緩存。
  此時MySQL值為1，Redis值為0，緩存不一致。

• 先刪除緩存再更新數(shù)據(jù)：
  不行。v初始值為0，更新請求A先刪除緩存，此時過來一個讀請求B，發(fā)現(xiàn)沒有緩存，讀取MySQL，獲取值為0，此時更新請求A將MySQL的0改為1，讀請求B將Redis v的值改為0，緩存不一致。

• 延時雙刪：
  可以。是最終一致性的方案。
  延遲：更新MySQL后，隔一段時間再刪除緩存，一般間隔0.3-~1.5秒左右，略大于一個讀請求周期的耗時即可。
  雙刪：更新數(shù)據(jù)庫的前后都刪除一遍緩存。
  v初始值為0，更新請求A先刪除緩存，此時讀請求B過來，發(fā)現(xiàn)沒有緩存，去查MySQL后載入緩存，然后更新請求A更新MySQL更新v值為1，再等一段時間，再次刪除緩存。此時讀請求B查詢的是0（為了保證全局的最終一致性，只能犧牲查詢請求B），更新請求A中，MySQL和緩存數(shù)據(jù)一致，都是1。
  延遲雙刪的延遲，是為了保證查詢請求B走完流程，如果刪除的早，更新請求A先走完流程，那還是會被讀請求B的將老數(shù)據(jù)載入緩存。
  延時可通過用Laravel queue或者其它消息中間件去實現(xiàn)。
  那如何保證，第二次刪除成功呢？
  添加重試機制，如果刪除失敗，可再刪除3次。

查數(shù)據(jù)后，保證Redis讀取的是最新的數(shù)據(jù)

不存在一致性問題。
數(shù)據(jù)沒有寫操作。

小結

可見若數(shù)據(jù)發(fā)生了變動，無論以上方案怎么搞，都可能會有不一致的情況。
即使是延遲雙刪，也會增加運維成本，多了一些工序，它們的高可用又是一類問題。

如果有MySQL+Redis的鎖機制，那么其它請求就會阻塞，性能就下降。反過來就影響一致性，這也是CAP三選二的體現(xiàn)。

換個角度講，對于緩存一致性問題，刪除緩存，比更新緩存相對可靠。

• 如果用更新緩存策略：兩個更新的并發(fā)請求，更新MySQL的順序是一種順序，受網(wǎng)絡波動和卡機的影響，更新緩存可能又一種順序，這可能導致緩存與MySQL值不一致，緩存內部的可能是個錯值。
• 如果用刪除緩存策略：兩個更新的并發(fā)請求，更新MySQL的順序是一種順序，受網(wǎng)絡波動和卡機的影響，緩存也是被刪除。最多其它讀請求把舊值又給緩存了進去，但至少是個舊值，而不是個錯值。

簡單的兜底策略

加上緩存過期時間。避免MySQL與緩存長期不一致，對實時性要求越高，則緩存過期時間越少。
一些粒度更細的自定義存儲方式，用不了Redis對key的自動過期功能，可添加時間戳字段，用程序邏輯控制過期。文章來源地址http://www.zghlxwxcb.cn/news/detail-841785.html

Canal組件的策略

• 官網(wǎng)：https://github.com/alibaba/canal
• 簡介：Canal是用于解決緩存一致性問題的組件。由阿里巴巴開源，Java編寫的C/S架構的軟件。它的服務端可以偽裝成MySQL從機，實時捕獲 MySQL 主機的bin log，并將變更事件推送到消息隊列或者其它存儲中，以實現(xiàn)實時數(shù)據(jù)同步、對數(shù)據(jù)倉庫的實時分析等應用場景。
• 客戶端支持：支持Java、C#、Go、PHP、Python、Rust、NodeJs客戶端。
• 支持同步Kafka、ElasticSearch、HBase、RocketMQ、RabbitMQ、pulsarMQ、不支持直連Redis。
• 前置知識：一文讀懂MySQL7大日志（slow、redo、undo、bin、relay、general、error）和簡單搭建MySQL主從復制。
• Linux環(huán)境，MySQL主機配置

可參考https://github.com/alibaba/canal/wiki/QuickStart

vim /etc/my.cnf
在[mysqld]下寫入以下配置
server-id=180     //主機標識，得有一個唯一編號
log-bin=mysql-bin //bin log日志名
binlog_format=row //注意這里一定要用row，用statement或mixed，canal將無法解析
binlog-do-db=test //數(shù)據(jù)庫名


service mysql restart 保存后重啟

確認bin log是否開啟
select @@sql_log_bin;
+---------------+
| @@sql_log_bin |
+---------------+
|             1 |
+---------------+


登錄mysql命令行
CREATE USER canal IDENTIFIED BY 'canal';  
GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO '從機用戶名'@'%';
alter user 'canal'@'%' identified with mysql_native_password by '從機密碼，這里設置成canal';
FLUSH PRIVILEGES;

• Linux環(huán)境，Canal配置

不管是不是Java開發(fā)者，不需要安裝JDK或者JRE
mkdir /usr/local/cancl
cd /usr/local/cancl
wget https://github.com/alibaba/canal/releases/download/canal-1.1.7/canal.deployer-1.1.7.tar.gz
tar zxf canal.deployer-1.1.7.tar.gz

修改配置文件
vim /usr/local/canal/conf/example/instance.properties
canal.instance.mysql.slaveId=1 //去掉注釋，并修改為非主庫server-id的數(shù)據(jù)
canal.instance.master.address=127.0.0.1:3306 //主庫的IP:Port
canal.instance.dbUsername=從機用戶名
canal.instance.dbPassword=從機密碼


啟動，改配置后記得重啟。
/usr/local/canal/bin/startup.sh


查看
ps aux | grep canal

• Java或其它語言配置canal客戶端：https://github.com/alibaba/canal。
• PHP canal客戶端配置：

git clone https://github.com/xingwenge/canal-php.git
cd canal-php
composer install
php src/sample/client.php
只要沒提示Socket error: Connection refused (SOCKET_ECONNREFUSED)，就說明連接成功。

示例代碼如下：
需要注意兩個地方
$client->connect("127.0.0.1", 11111);
參數(shù)1的值是canal server的ip。
參數(shù)2的值是/usr/local/canal/conf/canal.properties文件中的canal.port項，遠程連接記得要開放端口。
$client->subscribe("1", "example", ".*\\..*");
參數(shù)1是/usr/local/canal/conf/example/instance.properties文件的canal.instance.mysql.slaveId項。
參數(shù)2是/usr/local/canal/conf/example，example的目錄名，一般不動他，可以配置多個。
參數(shù)3有個默認值，排除某個庫的某個表。

try {
    $client = CanalConnectorFactory::createClient(CanalClient::TYPE_SOCKET_CLUE);
    # $client = CanalConnectorFactory::createClient(CanalClient::TYPE_SWOOLE);

    $client->connect("127.0.0.1", 11111);
    $client->subscribe("1", "example", ".*\\..*");
    # $client->subscribe("1001", "example", "db_name.tb_name"); # 設置過濾

    while (true) {
        $message = $client->get(100);
        if ($entries = $message->getEntries()) {
            foreach ($entries as $entry) {
                Fmt::println($entry);
            }
        }
        sleep(1);
    }   

    $client->disConnect();
} catch (\Exception $e) {
    echo $e->getMessage(), PHP_EOL;
}


//當出現(xiàn)以下字樣時，說明聯(lián)調成功。
================> binlog[mysql-bin.000044 : 3130],name[test,cs], eventType: 2
-------> before
id : 1  update= false
num : 6  update= false
-------> after
id : 1  update= false
num : 7  update= true

性能：
官方給出的消費速度：sql insert 10000 事件，32秒消耗完成。消費速度 312.5 條/s。
實測消費速度遠高于官方的消費速度，1C1G的本地搭建的服務器：
表中共10000條，不加where全部更新，全部同步耗時2.5秒。
實測平均4000/s的消費速度，意味著每秒有略低于4000個redis key被修改，配置更高的服務器性能將會更好。
這速消費度，大部分的后端接口qps都趕不上，所以足以應對99%的業(yè)務場景。

• 對于PHP cancel二次修改，集成到Laravel框架的思路

這種不怎么參與業(yè)務，可以集成到框架，也可以不集成，在服務器上單獨放一個目錄去，cli模式下直接跑也行。

方案1，粗略的整理：將這個包放進laravel的app/Libs中，所有目錄結構均不改動，跟框架邏輯無關，僅僅變動跟隨Git同步。
二開，redis的連接參數(shù)可以硬編碼，也可以讀取.env的配置，正則匹配獲取，要寫在while(true)的外面（指的是cancal-php/src/sample/client.php中的while(true)）。

方案2，細致的整理：因為目前項目用不上，所以暫時不準備實操，但是思路得有，示例：
composer中的配置，需要集成到框架的composer中，
    "require": {
        "google/protobuf": "^3.8",
        "php":  ">=5.6",
        "clue/socket-raw": "^1.4"
    },
    "autoload": {
        "psr-4": {
            "Com\\Alibaba\\Otter\\Canal\\Protocol\\": "src/protocol/Com/Alibaba/Otter/Canal/Protocol/",
            "GPBMetadata\\": "src/protocol/GPBMetadata/",
            "xingwenge\\canal_php\\": "src/"
        }
    }
cancal-php/src/sample/client.php的文件也就不到40行。
這塊邏輯可以放到框架的app/Libs下，也可以放到app\Console\Commands，用php artisan xxx命令去執(zhí)行。
不是依賴包內的其它文件，放在app/Libs/cancal目錄下。

核心邏輯接口再src/Fmt.php文件的printLn方法中提供了的可用參數(shù)，
有數(shù)據(jù)庫名、表名、操作主鍵、更改前的值、更改后的值、以及DML動作類型，可以根據(jù)這個二開，根據(jù)自定義的命名規(guī)則，配置自定義redis的動作。

到了這里，關于深入理解高并發(fā)下的MySQL與Redis緩存一致性問題（增刪改查數(shù)據(jù)緩存的一致性、Canal、分布式系統(tǒng)CAP定理、BASE理論、強、弱一致性、順序、線性、因果、最終一致性）的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！