一贷掖,writeConcern
writeConcern 決定一個寫操作落到多少個節(jié)點上才算成功嫡秕。writeConcern 的取值包括:
? 0:發(fā)起寫操作,不關(guān)心是否成功苹威;
? 1~集群最大數(shù)據(jù)節(jié)點數(shù):寫操作需要被復(fù)制到指定節(jié)點數(shù)才算成功昆咽;
? majority:寫操作需要被復(fù)制到大多數(shù)節(jié)點上才算成功。
發(fā)起寫操作的程序?qū)⒆枞綄懖僮鞯竭_(dá)指定的節(jié)點數(shù)為止
1.1 writeConcern測試
//進(jìn)入主節(jié)點牙甫,執(zhí)行
conf=rs.conf()
conf.members[2].slaveDelay = 5//延遲5秒
conf.members[2].priority = 0//投票優(yōu)先級設(shè)置為0
rs.reconfig(conf)
db.test.insertOne({count: 1}, {writeConcern: {w: 3}})//5秒后執(zhí)行完成
//返回
{
"acknowledged" : true,
"insertedId" : ObjectId("60072bacd28a60ee717d761e")
}
db.test.insertOne({count:2},{writeConcern: {w: 4, wtimeout:3000}})//超過節(jié)點數(shù)
//返回
WriteConcernError({
"code" : 100,
"codeName" : "UnsatisfiableWriteConcern",
"errmsg" : "Not enough data-bearing nodes",
"errInfo" : {
"writeConcern" : {
"w" : 4,
"wtimeout" : 3000,
"provenance" : "clientSupplied"
}
}
})
//查詢
db.test.find({count:2})
//返回
{ "_id" : ObjectId("60072f63d28a60ee717d7623"), "count" : 2 }
db.test.insertOne({count:3},{writeConcern: {w: 3, wtimeout:3000}})//設(shè)置3秒超時掷酗,返回會報錯
//返回
WriteConcernError({
"code" : 64,
"codeName" : "WriteConcernFailed",
"errmsg" : "waiting for replication timed out",
"errInfo" : {
"wtimeout" : true,
"writeConcern" : {
"w" : 3,
"wtimeout" : 3000,
"provenance" : "clientSupplied"
}
}
})
//主節(jié)點查詢
db.test.find({count:3})
//返回
{ "_id" : ObjectId("60072c34d28a60ee717d7620"), "count" : 3 }
//過了5秒,進(jìn)入第二個從節(jié)點執(zhí)行
db.test.find({count:3})
//返回
{ "_id" : ObjectId("60072c34d28a60ee717d7620"), "count" : 3 }
writeConcern大于總節(jié)點數(shù)窟哺,或者等于總節(jié)點數(shù)但有一個節(jié)點故障泻轰,寫入會報錯,但數(shù)據(jù)還是會寫入且轨,但這種錯誤沒有必要浮声,重要數(shù)據(jù)設(shè)置成majority就可以了
設(shè)置超時,雖然會報錯殖告,當(dāng)數(shù)據(jù)實際上是主節(jié)點先寫入阿蝶,然后再等待其他節(jié)點同步數(shù)據(jù)時發(fā)生超時,數(shù)據(jù)還是已經(jīng)入庫了黄绩,也不會因為超時錯誤停止同步
通常應(yīng)對重要數(shù)據(jù)應(yīng)用 {w: “majority”}羡洁,普通數(shù)據(jù)可以應(yīng)用 {w: 1} 以確保最佳性能。
writeConcern寫操作返回耗時受到同步及從節(jié)點性能影響爽丹,但并不會顯著增加集群壓力筑煮,因此無論是否等待,寫操作最終都會復(fù)制到所有節(jié)點上粤蝎。設(shè)置 writeConcern 只是讓寫操作等待復(fù)制后再返回而已
二真仲,讀數(shù)據(jù)
作為集群數(shù)據(jù)庫讀取時需要關(guān)注2個問題:
1,去哪讀-readPreference
2初澎,數(shù)據(jù)隔離性-readConcern
2.1 readPreference
readPreference 決定使用哪一個節(jié)點來滿足正在發(fā)起的讀請求秸应。可選值包括:
? primary: 只選擇主節(jié)點碑宴;
? primaryPreferred:優(yōu)先選擇主節(jié)點软啼,如果不可用則選擇從節(jié)點;
? secondary:只選擇從節(jié)點延柠;
? secondaryPreferred:優(yōu)先選擇從節(jié)點祸挪,如果從節(jié)點不可用則選擇主節(jié)點;
? nearest:選擇最近的節(jié)點贞间;
除此之外還可以通過標(biāo)簽來選擇讀取節(jié)點
2.1 readConcern
? available: 讀取所有可用數(shù)據(jù)贿条;
? local:讀取屬于當(dāng)前分片的所有可用數(shù)據(jù)雹仿;
? majority:讀取大部分已提交的;
? linearizable:線性讀整以;
? snapshot:快照讀胧辽;
available與local的區(qū)別
在復(fù)制集下面local和available沒有區(qū)別,區(qū)別在于分片集遷移數(shù)據(jù)時悄蕾,當(dāng)chunk x需要從shard1遷移到shard2上面的過程中票顾,在shard1,shard2上面都有chunk x的數(shù)據(jù)帆调,但shard1為負(fù)責(zé)方奠骄。所有對chunk x的讀寫操作都會進(jìn)入shard1,如果指定對shard2讀取番刊,available會讀取包含chunk x的數(shù)據(jù)含鳞,而local只會讀取當(dāng)前分片負(fù)責(zé)的數(shù)據(jù)
majority
首先主節(jié)點寫入數(shù)據(jù),然后同步給從節(jié)點芹务,當(dāng)主節(jié)點收到大部分節(jié)點的寫入確認(rèn)后蝉绷,再同步從節(jié)點數(shù)據(jù)已大部分節(jié)點寫入,收到的從節(jié)點就認(rèn)為這個數(shù)據(jù)已經(jīng)是majority的枣抱,可被majority讀取的熔吗。當(dāng)有個節(jié)點沒有收到數(shù)據(jù)或者majority確認(rèn),但是大部分節(jié)點已經(jīng)寫入了佳晶,當(dāng)前節(jié)點的視角是沒有該數(shù)據(jù)的
majority作用:
當(dāng)主節(jié)點掛掉前將數(shù)據(jù)x=1,改為x=2桅狠,數(shù)據(jù)還沒同步給從節(jié)點,沒有設(shè)置majority轿秧,主節(jié)點讀到x=2,主節(jié)點就掛掉了中跌,x=2就再也無法獲取,原來的就變成了臟讀菇篡。
linearizable
majority大部分時候都能保證不會出現(xiàn)臟讀漩符,有一種特殊的情況,majority并不能很好支持驱还。
存在server1嗜暴,server2連接著node1,node1為主節(jié)點议蟆,當(dāng)node1與其他節(jié)點失聯(lián)闷沥,當(dāng)server2可以連接node1。這時server1通過選舉重新連接到node2作為主節(jié)點咪鲜,往node2寫入數(shù)據(jù)。但是server2卻認(rèn)為node1是主節(jié)點撞鹉,獲取不到對應(yīng)數(shù)據(jù)疟丙,導(dǎo)致數(shù)據(jù)不一致颖侄。這種情況需要設(shè)置linearizable,這個配置在獲取數(shù)據(jù)前享郊,或從其他節(jié)點檢查數(shù)據(jù)是否是真的最新览祖。
三,因果一致性
有的博客包括極客時間上面提到炊琉,寫入mongo時展蒂,設(shè)置writeConcern=majority,讀取時設(shè)置readPreference=secondary,readConcern=majority就可以得到很好的性能且數(shù)據(jù)一致
其實不是的苔咪,先解釋下這樣子設(shè)置的意思锰悼,首先寫保證大部分節(jié)點已經(jīng)寫入,讀取時選擇從節(jié)點团赏,且是被大部分從節(jié)點有被寫入的數(shù)據(jù)才能被讀取箕般。
這種情況會出現(xiàn)數(shù)據(jù)不一致:當(dāng)前有一個一主二從的集群,當(dāng)主節(jié)點與從節(jié)點1數(shù)據(jù)被寫入了舔清,當(dāng)時從節(jié)點2沒有被寫入丝里,在主節(jié)點和從節(jié)點1的視角看,這條數(shù)據(jù)已經(jīng)被寫入体谒,且是mayjority的杯聚,但是如果訪問的從節(jié)點2視角看,是不存在這條數(shù)據(jù)的抒痒,當(dāng)我們設(shè)置readPreference=secondary時幌绍,剛好驅(qū)動剛好選擇的是從節(jié)點2,數(shù)據(jù)會不一致
實驗:
首先搭建一個一主二從的集群评汰,進(jìn)入從節(jié)點2的shell纷捞,執(zhí)行
/*
把節(jié)點2鎖住,用來模擬從節(jié)點延遲
不要設(shè)置延遲節(jié)點來模擬節(jié)點延遲被去,在golang的驅(qū)動庫中就算延遲節(jié)點沒有設(shè)置隱藏主儡,也不會選為讀取節(jié)點
*/
db.fsyncLock()
下面這段代碼有三組測試:
1,沒有使用session惨缆,會出現(xiàn)數(shù)據(jù)不一致
2糜值,多個session,CausalConsistency為true坯墨,會出現(xiàn)不一致
3寂汇,單個session,CausalConsistency為false捣染,會出現(xiàn)不一致骄瓣,當(dāng)把SetCausalConsistency(false)
這句刪除,驅(qū)動默認(rèn)為true耍攘,數(shù)據(jù)一致
所以在不考慮事務(wù)的情況榕栏,需要寫入或者修改的數(shù)據(jù)能被立馬讀到需要滿足:
1畔勤,寫與讀在同一個session
2,session的CausalConsistency為true
更多CausalConsistency的介紹:
1扒磁,https://docs.mongodb.com/manual/reference/server-sessions/
2庆揪,https://docs.mongodb.com/manual/core/read-isolation-consistency-recency/#causal-consistency
3,https://docs.mongodb.com/manual/core/transactions/
package main
import (
"context"
"fmt"
"go.mongodb.org/mongo-driver/bson"
"go.mongodb.org/mongo-driver/mongo"
"go.mongodb.org/mongo-driver/mongo/options"
"go.mongodb.org/mongo-driver/mongo/readconcern"
"go.mongodb.org/mongo-driver/mongo/readpref"
"go.mongodb.org/mongo-driver/mongo/writeconcern"
"sync"
"time"
)
func main() {
noSessionTest()
multiSessionTest()
singleSessionTest()
}
func newCollection(client *mongo.Client) *mongo.Collection {
option := options.CollectionOptions{}
return client.Database("alex").
Collection("test",
option.SetWriteConcern(writeconcern.New(writeconcern.WMajority())).
SetReadPreference(readpref.Secondary()).
SetReadConcern(readconcern.Majority()))
}
func newClient() *mongo.Client {
uri := "mongodb://member1.example.com:28017,member2.example.com:28018,member3.example.com:28019/admin?replicaSet=rs0"
ctx := context.Background()
client, err := mongo.Connect(ctx, options.Client().ApplyURI(uri))
if err != nil {
panic(err)
}
err = client.Ping(ctx, nil)
if err != nil {
panic(err)
}
fmt.Println("Successfully connected and pinged.")
return client
}
func multiSessionTest() {
ctx := context.TODO()
client := newClient()
opts := options.Session().
SetDefaultReadConcern(readconcern.Majority()).
SetDefaultReadPreference(readpref.Secondary())
sess, err := client.StartSession(opts)
if err != nil {
panic(err)
}
var insertId interface{}
err = mongo.WithSession(ctx, sess, func(sessionContext mongo.SessionContext) error {
coll :=newCollection(client)
insertId = insert(sessionContext,coll)
return nil
})
sess, err = client.StartSession(opts)
if err != nil {
panic(err)
}
err = mongo.WithSession(ctx, sess, func(sessionContext mongo.SessionContext) error {
coll :=newCollection(client)
find(sessionContext,coll,insertId)
return nil
})
}
func singleSessionTest() {
ctx := context.TODO()
client := newClient()
opts := options.Session().
SetDefaultReadConcern(readconcern.Majority()).
SetDefaultReadPreference(readpref.Secondary()).
SetCausalConsistency(false)
sess, err := client.StartSession(opts)
if err != nil {
panic(err)
}
var insertId interface{}
err = mongo.WithSession(ctx, sess, func(sessionContext mongo.SessionContext) error {
coll :=newCollection(client)
insertId = insert(sessionContext,coll)
find(sessionContext,coll,insertId)
return nil
})
}
func noSessionTest() {
ctx := context.TODO()
client := newClient()
coll := newCollection(client)
insertId := insert(ctx, coll)
find(ctx,coll,insertId)
}
func insert(ctx context.Context, coll *mongo.Collection) (insertId interface{}) {
res, err := coll.InsertOne(ctx, bson.M{"time": time.Now().Unix()})
if err != nil {
panic(err)
}
return res.InsertedID
}
func find(ctx context.Context, coll *mongo.Collection, insertId interface{}) {
wait := sync.WaitGroup{}
wait.Add(100)
for i := 0; i < 100; i++ {
go func() {
result := coll.FindOne(ctx, bson.M{"_id": insertId})
if result.Err() != nil {
fmt.Println(result.Err())
} else {
fmt.Println(true)
}
wait.Done()
}()
}
wait.Wait()
}