deleteMany/remove都可以添加writeConcern參數，表明是否關注writeConcern
What’s the difference between “deletemany” and “remove” in mongodb?
As far as I can say,
db.collection.deleteMany
Returns:
A document containing:
A boolean acknowledged as true if the operation ran with write concern or false if write concern was disabled
deletedCount containing the number of deleted documents
REF: db.collection.deleteMany
Where as
db.collection.remove
return WriteResult
And to remove a single document, there a similar command, db.collection.removeOne where as with db.collection.remove you need to set and option called justOne option to limit delete to 1 document.
Otherwise I guess they are similar.
node.js drivers
When talking about node.js drivers, remove has been deprecated (and may be removed in future releases) and deleteOne or deleteMany.
Hope this makes sense …
一樣的效果，返回值不一樣。
They do the same. The difference is the values that return.
With remove():
db.ticker.remove({“name”: “Bitcoin”})
WriteResult({ “nRemoved” : 2 })
With deleteMany():
db.ticker.deleteMany({“name”: “Bitcoin”})
{ “acknowledged” : true, “deletedCount” : 2 }
writeConcern是寫入策略，保證副本響應了primary的數據寫入操作後，primary才響應。
MongoDB支持客戶端靈活配置寫入策略（writeConcern），以滿足不同場景的需求。
db.collection.insert({x: 1}, {writeConcern: {w: 1}})
writeConcern選項
MongoDB支持的WriteConncern選項如下
w: 數據寫入到number個節點才向用客戶端確認
{w: 0} 對客戶端的寫入不需要發送任何確認，適用於性能要求高，但不關注正確性的場景
{w: 1} 默認的writeConcern，數據寫入到Primary就向客戶端發送確認
{w: “majority”} 數據寫入到副本集大多數成員後向客戶端發送確認，適用於對數據安全性要求比較高的場景，該選項會降低寫入性能
j: 寫入操作的journal持久化後才向客戶端確認
默認爲”{j: false}，如果要求Primary寫入持久化了才向客戶端確認，則指定該選項爲true
wtimeout: 寫入超時時間，僅w的值大於1時有效。
當指定{w: }時，數據需要成功寫入number個節點纔算成功，如果寫入過程中有節點故障，可能導致這個條件一直不能滿足，從而一直不能向客戶端發送確認結果，針對這種情況，客戶端可設置wtimeout選項來指定超時時間，當寫入過程持續超過該時間仍未結束，則認爲寫入失敗。
{w: “majority”}解析
{w: 1}、{j: true}等writeConcern選項很好理解，Primary等待條件滿足發送確認；但{w: “majority”}則相對複雜些，需要確認數據成功寫入到大多數節點纔算成功，而MongoDB的複製是通過Secondary不斷拉取oplog並重放來實現的，並不是Primary主動將寫入同步給Secondary，那麼Primary是如何確認數據已成功寫入到大多數節點的？
Client向Primary發起請求，指定writeConcern爲{w: “majority”}，Primary收到請求，本地寫入並記錄寫請求到oplog，然後等待大多數節點都同步了這條/批oplog（Secondary應用完oplog會向主報告最新進度)。
Secondary拉取到Primary上新寫入的oplog，本地重放並記錄oplog。爲了讓Secondary能在第一時間內拉取到主上的oplog，find命令支持一個awaitData的選項，當find沒有任何符合條件的文檔時，並不立即返回，而是等待最多maxTimeMS(默認爲2s)時間看是否有新的符合條件的數據，如果有就返回；所以當新寫入oplog時，備立馬能獲取到新的oplog。
Secondary上有單獨的線程，當oplog的最新時間戳發生更新時，就會向Primary發送replSetUpdatePosition命令更新自己的oplog時間戳。
當Primary發現有足夠多的節點oplog時間戳已經滿足條件了，向客戶端發送確認。