大部分數據庫都支持多讀，一般是使用行鎖。
寫=插入（批量操作，id獨立生成，不實用自增）、更新、刪除
讀寫分離之外，還有降級，還有緩存讀寫，延遲處理等。
處理策略主要看用戶場景，秒殺場景和普通場景又不一樣。
CAP原則一只能滿足兩樣，所以要根據實際場景選擇合適的處理策略
讀在數據能力下是基本滿足不了高並發場景的，所以一般會使用緩存，
讀頻繁的可以考慮使用本地緩存，數據量稍大的可以使用遠程緩存，量大可以上集群，
實時要求高的可以考慮優先寫入緩存+寫入日志+ 寫數據庫
一致性要求高就寫日志+數據庫+緩存
實時要求不高就考慮批量寫入，減少數據庫資源占用
量超級大的就考慮分布式文件系統，或者分布式數據庫，分庫，分表，分區等等。
再撐不住了，考慮前端降級，一般降級只有秒殺、搶票場景。