儲存系統特點：難用、慢、場景多導致雜
很多情況下，可供選擇的儲存方案不止一套，選擇的時候需要考慮實現複雜度、效能、系統可用性、資料可靠性、 可擴充套件性等等非常多的條件，這些條件每乙個都不是絕對不可以犧牲的
以下內容以電商內容展開
插入訂單的冪等性問題：給訂單系統增加乙個「生成訂單號」的服務，這個服務返回乙個新的、全域性唯一的訂單號；在使用者進入建立訂單的頁面時，前端頁面先呼叫這個生成訂單號服務得到乙個訂單號，在使用者提交訂單的時候，在建立訂單的請求中帶著這個訂單號；重複時會報錯，當然這種情況直接返回給前端訂單建立成功就可以了
訂單aba問題：使用版本號來解決，即樂觀鎖思想；
如下圖場景：先提交訂單號666，發現應該是提交888，因此666之後提交了888，如果666的響應丟失，會發現最終落地的訂單號是666
解決：每次都進行version的判斷，要麼會888更新失敗，要麼會新的666更新失敗，這樣就是冪等更新了
訂單資料量過大：存檔歷史訂單、分庫分表
物件儲存核心架構：
資料訪問的流程：請求乙個 key 時，閘道器首先去元資料中查詢這個 key 的元資料；
根據元資料中記錄的物件長度，計算出物件有多少塊，接下來分塊並行處理；
對於每個塊兒，還需要再去元資料中，找到它被放在哪個容器中，不同的系統 選擇實現的方式也不一樣，有用雜湊分片的，也有用查表法把對應關係儲存在元資料中的；
找到容器之後，再去元資料中查詢容器的 n 個副本都分布在哪些資料節點上；
最後，閘道器 直接訪問對應的資料節點讀寫資料就可以了
需要實現暫存購物車和使用者購物車，暫存購物車推薦使用cookie或localstorage來儲存，使用者購物車可以用mysql（購物車表）或redis（key為使用者id，value為hash儲存購物車列表）來儲存
使用資料庫事務來保證
跨系統則需要分布式事務
使用elasticsearch來構建，本質為倒排索引
es的倒排索引物理結構也是一顆查詢樹
1 sql本身問題，善用explain進行分析
注意涉及的量級
索引limit優化等
2 是否可以加快取來減少資料庫查詢次數、改進快取置換策略
3 可以上線乙個定時監控和殺掉慢 sql 的指令碼。這個指令碼每分鐘執行一次，檢測上一分鐘內，有沒有執行時間超過一分鐘（這個閾值可以根據實際情況調整）的慢 sql， 如果發現，直接殺掉這個會話
4 可以做乙個簡單的靜態頁面的首頁作為降級方案，只要包含商品搜尋欄、大的品類和其他頂級功能模組入口的鏈結就可以了
5 可以考慮對熱點資料做隔離
6 資料庫主從分離，把非業務請求的資料庫查詢遷移到單獨的從庫上
7 限流、熔斷
redis cluster、基於**的方式、客戶端定製
基於**的方式：**負責在客戶端和 redis 節點之間**請求和響應、監控集群中所有redis節點的狀態，有問題則進行主從切換、維護集群元資料
客戶端定製：
1 如下圖，訂單系統有現成的資料變更訊息可以訂閱，這樣更新快取是乙個不錯的選擇，因為實現起來很簡單，對系統的其他模組完全沒有侵入
2 如果沒有資料更新的mq可以訂閱，可以用下圖，更通用：把負責更新快取的服務偽裝成乙個 mysql 的從節點，從 mysql 接收 binlog，解析 binlog 之後，可以得到實時的資料變更資訊，然後根據這個變更資訊去更新 redis 快取
資料庫之間的同步也同理：
為了增加同步速度，可以並行進行資料同步；
並行需要結合業務，首先要知道兩個不同的訂單誰先更新誰後更新並不影響資料的一致性， 因為這兩個訂單完全沒有任何關係，但是同乙個訂單，如果更新的 binlog 執行順序錯了， 那同步出來的訂單資料真的就錯了；
因此先根據下游同步程式的消費能力，計算出需要多少併發，然後設定 mq 中主題的分割槽 （佇列）數量和併發數一致。因為 mq 是可以保證同一分區內，訊息是不會亂序的，所以 我們需要把具有因果關係的 binlog 都放到相同的分割槽中去，就可以保證同步資料的因果一致性，對應到訂單庫就是，相同訂單號的 binlog 必須發到同乙個分割槽上。
更換資料庫：
1 把舊庫的資料複製到新庫中，並開發乙個同步程式來實現新舊兩個資料庫實時同步
2 雙寫（使用開關控制，只寫舊庫、 只寫新庫和同步雙寫）、雙讀（使用開關控制，新、舊），先寫新讀新，穩定一段時間後，雙寫，先寫舊後寫新，如果寫新失敗，還是返回成功，但要記錄下日誌，後續用來驗證新庫，如果寫舊失敗，直接返回失敗
3 對比資料變更、補償（類似訂單系統這類時效性強的資料，可以依據訂單完成時間，每次只對比這個時間視窗內完成的訂單，發現不一致的情況後，直接用舊庫的訂單資料覆蓋新庫 的訂單資料就可以；
其他資料，可以看是否有資料更新時間，則可以利用這個更新時間，每次在舊庫取乙個更新時間視窗內的資料，去新庫上找相同主鍵的資料進行對比，發現資料不一致，還要對比一下更新時間，如果新庫資料的更新時間晚於舊庫資料，那可能是對比期間資料發生了變化，這種情況暫時不要補償，放到下個時間視窗去繼續對比；
另外，時間視窗的結束時間，不要選取當前時間，而是要比當前時間早一點兒，比如 1 分鐘前，避免去對比正在寫入的資料；
如果沒有，那只能去舊庫讀取 binlog，獲取資料變化，然後去新庫對比和補償）
kafka：容量小、查詢能力差、吞吐量強
hdfs：容量大、查詢能力強、吞吐量弱
時序資料庫：都還可以，但是目前只適用於監控資料
後續改進方向：讓kafka有高容量的儲存
海量資料的查詢建議根據不同的業務來選擇不同的儲存系統、方案
後端開發入門實戰
python2.7 flask2.0 pymysql 系統服務端開發倉庫結構 static 靜態資源資料夾 templates 模板資料夾 init py 初始化檔案 user sign up.py blueprint user login.py blueprint models.py 資料庫關係模...
網路營銷實戰課 筆記2
1.獲取有效流量的具體步驟 使用者調查 內容製作 投放渠道 資料反饋 內容調優 a.使用者調查，同時設定了明確的目標 b.內容製作 打情感牌 追求夢想，只過1 的生活，超長情感自述帖 c.投放渠道 d.資料反饋 12月13日內容發布試水 e.調整優化 如果驗證轉化結果非常優秀，投入擴大！2.在做市場...
網路營銷實戰課 筆記5
1.99 的人都錯誤的看待內容製作 誤區 99 的人是怎麼製作內容的?a.每天死憋 big idea b.把營銷工作和最終的文案劃等號 c.我覺得 使用者需要這個內容 d.盲目追求速成 追求沒有意義的數量 應該怎麼做 點線面，到 營銷內容產品化 的過程 內容製作的發展過程 0使用者的時候 點 有一部...