假如有乙個購票系統：
三個使用者a,b,c希望同時訂購一張票，可能會讀取到同一條未被銷售的車票記錄，然後再進行更新（購買），為了確保資料的一致性，防止更新丟失，
通常的解決方法是使用updlock 加入更新鎖，不過這樣會造成資源爭用和等待，在併發量很高的情況下，會對效能造成較大的影響。
樂觀鎖定的解決方案：
給表加入乙個timestamp型別的字段，每次更新行資料時，該行中的該列都會自動更新
在獲取並更新記錄的時候，通過比較該列值，就可判斷是否已經被更新過。
例：select top 1 @id=id,
@timestp=timestp
from coupon
where isused=0
-- 更新時比較timestamp欄位是否已經改變，發生改變則更新失敗
update …… where id=@id and timestp=@timestp
這種方法也存在一些問題:更新任何欄位時都會更新timestamp欄位,可能會造成一些錯誤的更新判斷。
kafka consumer防止資料丟失
kafka最初是被linkedin設計用來處理log的分布式訊息系統，因此它的著眼點不在資料的安全性 log偶爾丟幾條無所謂 換句話說kafka並不能完全保證資料不丟失。儘管kafka官網聲稱能夠保證at least once，但如果consumer程序數小於partition num 這個結論不一...
kafka consumer防止資料丟失
kafka最初是被linkedin設計用來處理log的分布式訊息系統，因此它的著眼點不在資料的安全性 log偶爾丟幾條無所謂 換句話說kafka並不能完全保證資料不丟失。儘管kafka官網聲稱能夠保證at least once，但如果consumer程序數小於partition num，這個結論不一...
kafka consumer防止資料丟失
kafka最初是被linkedin設計用來處理log的分布式訊息系統，因此它的著眼點不在資料的安全性 log偶爾丟幾條無所謂 換句話說kafka並不能完全保證資料不丟失。儘管kafka官網聲稱能夠保證at least once，但如果consumer程序數小於partition num 這個結論不一...