索引：

? ? ? ? 主鍵索引：表的id? ?（唯一 且? 不能為空）

? ? ? ? 唯一索引：表User 假設有account 字段 ，用戶名不重復? （唯一 可以為空）

? ? ? ? 復合索引：where() 的條件 用戶名，密碼 （無要求，無要求）

鎖：

? ? ? ? 悲觀鎖：（兩個人同時想要去上廁所 只有一個廁所 ， 只能A，B中的一個先上廁所即事務， 當上廁所的人 解決了后? 剩下的人才能使用廁所）

例子：
假設商品ID為1的商品只剩下一件庫存。用戶A和用戶B幾乎同時發起購買這個商品的請求。
用戶A開始一個事務，并執行SELECT * FROM products WHERE id = 1 FOR UPDATE;這個SQL語句。這個語句鎖住了商品ID為1的記錄，其他事務不能修改這個記錄直到用戶A的事務結束。
用戶B開始一個事務，并試圖執行同樣的操作。但是，由于用戶A已經加鎖了該商品，用戶B的查詢會被阻塞，直到用戶A釋放鎖。
悲觀鎖確保了用戶A和用戶B不會同時獲得這件商品的購買資格，只有一個用戶能夠成功購買。

? ? ? ? 樂觀鎖：（在車站進站的時候，檢票機【商城或者商品 】 在檢測到用戶 刷省份證的后? 會進行 放行的行動? ? 這個時候 A用戶【大人】? B用戶 【未成年 無身份證】 同時進入 。? 在商品來講就是超賣? 原始庫存10? ?即兩個請求同時進行 在商品的數據的庫存中-1? 但是只會減1?【此時的庫存為9】? ? ）

用戶A開始一個事務，并讀取了商品ID為1的記錄，此時不加鎖。記錄顯示有10件庫存。
用戶B也開始一個事務，并讀取了同樣的記錄，同樣不加鎖。記錄也顯示有10件庫存。
用戶A更新商品ID為1的記錄的stock_quantity減1，并嘗試提交事務。
用戶B也更新商品ID為1的記錄的stock_quantity減1，并嘗試提交事務。
在用戶A和用戶B都嘗試提交事務時，數據庫會檢查stock_quantity字段的值是否有沖突。由于兩個人都減少了1件庫存，現在庫存量為9件。數據庫會檢查自事務開始以來數據是否有過變更。在這個例子中，由于兩個人讀取的數據是一樣的，所以他們都認為庫存量是10件，并且都進行了減1的操作。因此，他們都會成功提交事務，并不會因為庫存量為9件而失敗。

商品超賣問題? 使用easyswoole 的消息隊列來解決。

事務：事務是數據庫中的一個重要功能，它允許一組數據庫操作要么全部成功，要么全部失敗。

rabbitmq:
RabbitMQ 是一個開源的消息隊列系統，它實現了高級消息隊列協議（AMQP）。AMQP 是一種消息傳遞中間件的標準協議，它定義了消息的傳輸、路由和隊列機制。RabbitMQ 提供了跨語言和跨平臺的客戶端庫，支持多種消息傳遞模式，包括點對點（Point-to-Point）、發布/訂閱（Publish/Subscribe）和路由（Routing）

memache:

異步和同步是消息傳遞和數據處理中的兩種常見模式，它們在不同的使用場景中有不同的優勢和應用。
? ?異步
使用場景：
高并發處理：當系統需要處理大量并發請求時，異步處理可以避免阻塞，提高系統吞吐量。
非實時性要求：對于不要求實時響應的場景，如日志收集、數據分析等，異步處理可以background執行，不影響主線程。
解耦合：異步通信可以減少系統組件之間的耦合，使得系統更加模塊化和靈活。
擴展性：異步模式便于擴展，可以通過增加消費者來處理更多的消息。
? 優點：
提高系統響應速度和吞吐量。
減少資源占用，因為多個操作可以并行處理。
增強系統的伸縮性，可以通過增加處理線程或實例來處理更多的任務。
? ?缺點：
可能會引入復雜性，如消息隊列的管理、消費者數量的調整等。
需要處理消息的順序性和一致性問題。
可能會增加系統的復雜性，如錯誤處理、重試邏輯等。
? ?同步
使用場景：
實時性要求高：如在線交易處理、實時通信等，需要立即得到響應。
操作重要：對于關鍵操作，需要確保執行完畢才能進行后續操作。
數據一致性要求高：在需要確保數據一致性的場景中，同步操作可以保證操作的順序性和一致性。
? ?優點：
保證操作的順序性和一致性。
易于理解和實現，尤其是對于簡單的單向操作。
適合需要即時反饋的場景。
? 缺點：
可能會降低系統的并發能力，因為一個操作可能會阻塞其他操作。
資源占用較大，因為操作需要依次執行。
系統的伸縮性較差，因為增加負載通常需要增加服務器資源。

新建目錄后，要執行的

php easyswoole.php server start

composer dump-autoload