29 分布式缓存重建并发冲突问题以及zookeeper分布式锁解决方案

上一篇 “分发层 + 应用层” 双层nginx 架构 之 应用层实现, 主要讲解了实现应用层数据缓存更新,为模板提供数据来源,本篇讲解分布式缓存重建冲突原因及利用zookeeper分布式锁解决缓存重建冲突问题。

  • 缓存重建什么意思呢?
    比如应用跑了一段时间,缓存(redis cluster)实例中的部分数据由于被LRU等算法或者其他手段清理了,这时候就需要重新到数据源中拉取数据,然后重新设置到缓存中。
  • 分布式缓存重建又是什么意思呢?
    比如在多个node节点上部署了相同的服务实例,对外提供服务,就会出现多个node分布式的去读取相同的数据,然后写入缓存(redis cluster)中

从缓存重建或分布式缓存重建从而会发现一个新的问题又来了,那就是 —— 分布式 重建缓存的并发冲突问题

分布式 重建缓存的并发冲突问题分析

  • 请求流量均匀分布(负载均衡)到所有的缓存服务实例中(前提是缓存服务部署到多个node 上),就会导致相同的商品id会打到不同的缓存服务实例,这样就导致了分布式缓存重建问题发生。(前面 28、27 章节讲解了使用nginx 分发层和应用层对外提供服务,根据 商品id 转发到应用层,应用层获取缓存服务实例数据,更新本地缓存并渲染),如下图所示:
通过lua 脚本将商品 id 相同的请求分发到固定的cache service 上

解决思路:部署多个cache service 实例,定义缓存实例请求地址列表,在nginx 应用层 计算 hash( 商品id ),然后对缓存实例地址列表数量取模,取出相应的缓存实例地址,请求到指定的 缓存实例node

  • mysql 源数据变更时,向缓存服务实例发送变更消息时,由于缓存服务是监听kafka topic的,所有一个kafka consumer 就会消费topic 中一个partition,那么多个缓存服务就会消费多个kafka partition,这样说来就会发送缓存重建问题了,如下图所示:
多实例kafka 消费问题

解决思路:在源数据服务的 kafka producer 中 ,发送message 加上 商品id即可,kafka 就会按照商品id 的方式进行分区

  • 上面讲源数据服务变更引入分区,只能解决单向缓存服务消费(不包含其他请求也请求到缓存服务情况),如果源数据服务变更打到cache service node 1 ,其他请求(nginx等等)请求打到cache service node2 ,那么问题就来了,因为nginx 分发层或者应用层的分发hash 分发策略是自己定义的,安装crc32 取hash 后取模的,你无法确定kafka 的分区策略,这里就无法统一了,这时候在高并发或者一些不确定因素的情况下就会出现两边都更新缓存了,就会出现冲突了。如下图所示:
数据冲突分析

上图有两条更新线:
a: nginx > cache service node1 > 源数据服务 > redis cluster
b: 源数据服务 > kafka > cache service node3 > 源数据服务 > redis cluster

很明显就可以发现问题了,最终redis cluster 中的最新数据并不是最新的。

基于以上分析,该怎么解决呢,前面两个点按照解决思路做好后,我们就可以单独解决第三点问题,这里可以使用分布式的共享锁,将不同node 实例的访问共享资源串行起来,分布式锁有很多,比如redis 分布式锁、zookeeper 分布式锁,笔者以zokeeper 分布式锁为例

基于zookeeper分布式锁的解决方案

zookeeper 分布式锁解决方案

基于问题三中分析图中加入zookeeper,谁先得到zookeeper 锁,谁先更新redis cluster ,同时缓存数据加入当时的时间(版本控制、比较),没有得到锁的等待。

zookeeper分布式锁的解决逻辑思路
  • 变更缓存重建或者空缓存请求重建,更新redis之前,先获取对应商品id的分布式锁
  • 拿到分布式锁后,做时间版本比较,如果自己的版本新于redis中的版本,那么就更新,否则就不更新
  • 如果拿不到分布式锁,那么就等待,不断轮询等待,直到自己获取到分布式的锁

以上就是本章内容,如有不对的地方,请多多指教,谢谢!

为了方便有需要的人,本系列全部软件都在 https://pan.baidu.com/s/1qYsJZfY

下章预告:主要讲解 “ 带你利用zookeeper 分布式锁解决缓存重建冲突”

作者:逐暗者 (转载请注明出处)

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 151,511评论 1 330
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 64,495评论 1 273
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 101,595评论 0 225
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 42,558评论 0 190
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 50,715评论 3 270
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 39,672评论 1 192
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,112评论 2 291
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 29,837评论 0 181
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 33,417评论 0 228
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 29,928评论 2 232
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,316评论 1 242
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 27,773评论 2 234
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,253评论 3 220
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 25,827评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,440评论 0 180
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 34,523评论 2 249
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 34,583评论 2 249

推荐阅读更多精彩内容