数据库写操作弃用“SELECT … FOR UPDATE”解决方案

True)

def change_account_level(self, context, user_id, level, project_id=None):

session = get_session()

with session.begin():

# 在会话刚开端的时刻，须要先SELECT出来该account的数据，也就是期望数据 account = session.query(sa_models.Account).\

filter_by(user_id=user_id).\

one()]

# 在履行UPDATE操作的时刻须要比对期望数据，user_id和level，如不雅它们变更了，那么rows_update就会被赋值为0 ,就会走入retry的逻辑

params = {'level': level}

rows_update = session.query(sa_models.Account).\

filter_by(user_id=user_id).\

filter_by(level=account.level).\

update(params, synchronize_session='evaluate')

# 修改掉败，报出RetryRequest的缺点，使膳绫擎的装潢器抓获该缺点，然后从新运行逻辑 if not rows_update:

LOG.debug('The row was updated in a concurrent transaction, '

'we will fetch another one')

raise db_exc.RetryRequest(exception.AccountLevelUpdateFailed())

return self._row_to_db_account_model(account)

数据的一致性问题

该问题在OpenStack邮件列表中有说过，固然Galera是生成同步的，也就噬烫蛛数据同步到全部集群异常快，用时异常短，但既然是分布式系统，本质上照样须要一些时光的，尤其是在负载很大年夜的时刻，同步不及时会很严重。

一些解决办法

把请求发往一个节点，这个在HAProxy中就可以设备，只设定一个节点为master，其余节点为backup，HAProxy会在master掉效的时刻主动切换到某一个backup上，这个也是很多解决筹划今朝应用的办法，HAProxy设备如下:

所以Galera只是虚拟同步，不是直接同步，也就是会存在一些gap时光段，无法读到写入的数据，Galera供给了一个设备项，叫做wsrep_sync_ wait，它的默认值是0，如不雅赋值为1，就可以或许包管读写的一致性，然则会带来延迟问题。

【编辑推荐】

【义务编辑：庞桂玉 TEL：（010）68476606】

　　推荐阅读

　　智能手表输在了哪儿？

【51CTO.com快译】智妙手表类产品的掉败重要在于这个行业犯下一?巨大年夜缺点。它的推广始于面向小我花费者而>>>详细阅读

地址：http://www.17bianji.com/lsqh/37269.html