Cassandra的batch,就是一次提交多个修改操作,节省传输请求的资源消耗。同时也可以理解为一种事务的解决方案——all or nothing,这些操作可以保证要么都成功要么都不成功,即原子性。这里需要注意几点:1:batch只保证原子性,要么都成功要么都失败,不保证隔离性。就是说可能存在某个时间点,batch的若干个修改只能读到一部分。同时batch也可以指定本次操作不需要保证原子性,这样显然性能会更高。另外counter因为不是幂等操作(多加了一次总和就变了)以及其实现比较复杂,不支持原子性的batch。2:batch中针对同一个row的操作会先合并再写,直接变成了一条操作。所以Cassandra是可以通过static column的batch来实现订单和余额在一个表,一个人的全部订单和余额放在一个row,对一个row key(userid)同时写成交新订单和余额修改操作,这样可以通过batch来实现原子性+隔离性。换句话说,只涉及到一个人的余额变化及订单成交,没有另一个人的余额变化,是可以搞的,而另一种事务的典型场景——一个人给另一个人转账,一个余额增加一个余额减少——这种跨行事务Cassandra应该至少目前是搞不定的。3:非batch的普通修改请求,在写失败的时候不会回滚,比如QUORUM的操作,写两份client才认为成功,假如3个节点只写成了一份另两份超时,cl
...
继续阅读
(43)