MongoDB的“read uncommit”和“write lock”是否相互衝突？
我正在閱讀 MongoDB 文件，其中提到了 read uncommit:
MongoDB allows clients to read documents inserted or modified before it commits these modifications to disk, regardless of write concern level or journaling configuration[ 1 ] 和關於 locks:Locks help guarantee that all writes to a single document occur either in full or not at all[ 2 ] 的內容。我的問題是，如果寫操作有鎖，那麼為什麼使用者可以讀取未送出的數據？
寫入首先在記憶體中完成，然後（非同步）刷新到磁碟。任何訪問文件的讀者都將立即獲得記憶體中的副本，而不是等待刷新到磁碟發生（否則數據庫將在性能方面受到磁碟限制）。關於鎖的引用適用於記憶體部分，並保證了記憶體中單個操作的原子性——它要麼完全發生，要麼不發生，對於讀者來說沒有中間狀態。因此，這兩者並不相互衝突，但您應該了解它們的功能。
如果您擔心特定寫入的磁碟持久性，那麼我建議您查看
j:true並w:majority寫入問題。第一個僅在寫入送出到日誌（在磁碟上）時返回 true，第二個僅在寫入到副本的多數成員（3 分之 2、5 分之 3 等）時才返回 true放。 請注意：與預設設置相比，這兩種寫入問題都會導致顯著的延遲（並且j:true選項會增加 IO），因此請確保它們是必需的並且性能水平是可以接受的這兩個選項（如您提供的連結所示）都不會阻止讀者讀取已在記憶體中送出但未刷新到磁碟的數據，但
j:true如果寫入失敗，則會通知您的應用程序寫入失敗磁碟，並且w:majority會通知您它是否已復製到其他成員（在故障轉移事件中將成為主要成員）。有了這些知識，您的應用程序可以根據操作的成功/失敗採取適當的操作（檢查、重試、其他）。