多執行緒多程序
計算密集型任務：使用多程序，因為能python有gil，多程序可以利用上cpu多核優勢；
io密集型任務：使用多執行緒，做io切換節省任務執行時間（併發）
乙個專案剛開始的時候是為了實現基本功能，隨著版本和功能的迭代，大資料和高併發成了軟體設計必須考慮的問題!
本質很簡單，乙個是慢，乙個是等。
兩者是相互關聯的，因為慢，所以要等，因為等，所以慢，解決了慢，也就解決了等，解決了等，也就解決了慢。
關鍵是如何解決慢和等，核心乙個是短，乙個是少，乙個是分流,最後乙個是集群/橫向擴張/讀寫分離/建立主從。
典型的mvc結構是請求->controller->model->dao->view，然後把頁面返回給使用者。要想短的話，
1，頁面靜態化- 使用者可以直接獲取頁面，不用走那麼多流程，比較適用於頁面不頻繁更新。
2，使用快取- 第一次獲取資料從資料庫準提取，然後儲存在快取中，以後就可以直接從快取提取資料。不過需要有機制維持快取和資料庫的一致性。
3，使用儲存過程-那些處理一次請求需要多次訪問資料庫的操作，可以把操作整合到儲存過程，這樣只要一次資料庫訪問就可以了。
4，批量讀取 - 高併發情況下，可以把多個請求的查詢合併到一次進行，以減少資料庫的訪問次數
5，延遲修改 - 高併發情況下，可以把多次修改請求，先儲存在快取中，然後定時將快取中的資料儲存到資料庫中，風險是可能會斷電丟失快取中的資料，
6, 使用索引 - 索引可以看作是特殊的快取，盡量使用索引就要求where字句中精確的給出索引列的值。
1，分表 - 把本來同一張表的內容，可以按照地區，類別等分成多張表，很簡單的乙個思路，但是要盡量避免分出來的多表關聯查詢。
2，分離活躍資料 - 例如登入使用者業務，註冊使用者很多，但是活躍的登入使用者很少，可以把活躍使用者專門儲存一張表，查詢是先查詢活躍表，沒有的話再查總表，這也類似與快取啦。
3， 分塊 - 資料庫層面的優化，對程式是透明的，查詢大資料只用找到相應塊就行。
1，集群 - 將併發請求分配到不同的伺服器上，可以是業務伺服器，也可以是資料庫伺服器。
2，分布式 - 分布式是把單次請求的多項業務邏輯分配到多個伺服器上，這樣可以同步處理很多邏輯，一般使用與特別複雜的業務請求。
3，cdn - 在網域名稱解析層面的分流，例如將華南地區的使用者請求分配到華南的伺服器，華中地區的使用者請求分配到華中的伺服器。
資料庫事務併發問題
乙個資料庫可能擁有多個訪問客戶端，這些客戶端都可以併發方式訪問資料庫。資料庫中的相同資料可能同時被多個事務訪問，如果沒有採取必要的隔離措施，就會導致各種併發問題，破壞資料的完整性。這些問題可以歸結為 5類，包括 3類資料讀問題 髒讀 幻象讀和不可重複讀 以及 2類資料更新問題 第一類丟失更新和第二類...
資料庫的併發問題
a事務讀取了b事務尚未提交的更改資料，並且在這個資料基礎上進行操作。如果此時恰巧b事務進行回滾，那麼a事務讀到的資料是根本不被承認的。以下是乙個取款事務和轉賬事務併發時引起的髒讀場景。時間轉賬事務a 取款事務b t1開始事務 t2開始事務 t3查詢賬戶餘額為1000元 t4取出500元，把餘額改為5...
資料庫事務併發問題
多個事務同時訪問資料庫時候，會發生下列5類問題，包括3類資料讀問題 髒讀，不可重複讀，幻讀 2類資料更新問題 第一類丟失更新，第二類丟失更新 1，髒讀 dirty read a事務讀取b事務尚未提交的更改資料，並在這個資料基礎上操作。如果b事務回滾，那麼a事務讀到的資料根本不是合法的，稱為髒讀。在o...