NOSQL(五)版本戳，nosql版本戳
《NoSQL精粹》读书笔记，转载请注明出处《jiq?钦's technical Blog》
“事务”是一个有用的工具，可以保证数据的强一致性，对于NoSQL不支持事务这一点，很多NoSQL支持者并不担心，因为面向聚合的NoSQL数据库中以聚合为单位的数据更新操作是原子的。
1“事务”的局限性
“事务”也有其局限性，有些更新操作无法封装到一个事务中，因为那会导致事务的打开时间过长。考虑这样一个例子，用户浏览商品时，看中了一个很便宜的商品，然后选中加入购物车，填入信用卡信息，寄送地址信息等，然后再确认提交订单之前，可能去吃了顿饭，或者去找信用卡去了，在这期间如果商品价格被修改了，或者寄送地址运费计算规则被修改了，那么提交订单时计算出来的支付价格将是错误的。
这时通过“版本戳”就可以很好地应对。而且在从“单服务器分布模型”迁移到“多服务器”时同样如此。版本戳可以确保在数据的读取和写入期间，没有其他人更新过此数据。这个例子中需要确保在写入订单时，没有人更新过订单中的商品信息、运费信息等。所以在提交订单时，需要将读取数据时记录下来的版本戳信息和现在数据库中的版本戳信息进行对比，若检测到首次读取之后到现在一直没有变化，将正确计算出支付价格。
HTTP协议更新资源时也会用到这种机制。某些数据库也提供了类似“条件更新”的机制，确保不会再旧数据上执行更新操作，有时也称作compare-and-set。
2 版本戳构建方法
? 计数器
? GUID
? 根据资源内容生产HASH码
? 时间戳
3 多服务器环境生成版本戳
在“单服务器”或者“主从复制”分布模型中，使用基本的版本戳生成方案就好，在这种情况下可以由主节点生成版本戳，而从节点必须使用主节点的版本戳。
在“对等复制”分布模型中则需要采用更为复杂的版本戳生成方式。