Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
晶之木
advanced-java
提交
184e8268
A
advanced-java
项目概览
晶之木
/
advanced-java
与 Fork 源项目一致
从无法访问的项目Fork
通知
3
Star
1
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
A
advanced-java
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
提交
Issue看板
前往新版Gitcode,体验更适合开发者的 AI 搜索 >>
未验证
提交
184e8268
编写于
8月 19, 2019
作者:
Q
Qimiao Chen
提交者:
GitHub
8月 19, 2019
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Fix typo
上级
302c3f5a
变更
1
隐藏空白更改
内联
并排
Showing
1 changed file
with
1 addition
and
1 deletion
+1
-1
docs/high-concurrency/redis-consistence.md
docs/high-concurrency/redis-consistence.md
+1
-1
未找到文件。
docs/high-concurrency/redis-consistence.md
浏览文件 @
184e8268
...
...
@@ -60,7 +60,7 @@
该解决方案,最大的风险点在于说,
**可能数据更新很频繁**
,导致队列中积压了大量更新操作在里面,然后
**读请求会发生大量的超时**
,最后导致大量的请求直接走数据库。务必通过一些模拟真实的测试,看看更新数据的频率是怎样的。
另外一点,因为一个队列中,可能会积压针对多个数据项的更新操作,因此需要根据自己的业务情况进行测试,可能需要
**部署多个服务**
,每个服务分摊一些数据的更新操作。如果一个内存队列里居然会挤压 100 个商品的库存修改操作,每
隔
库存修改操作要耗费 10ms 去完成,那么最后一个商品的读请求,可能等待 10
* 100 = 1000ms = 1s 后,才能得到数据,这个时候就导致**读请求的长时阻塞*
*
。
另外一点,因为一个队列中,可能会积压针对多个数据项的更新操作,因此需要根据自己的业务情况进行测试,可能需要
**部署多个服务**
,每个服务分摊一些数据的更新操作。如果一个内存队列里居然会挤压 100 个商品的库存修改操作,每
个
库存修改操作要耗费 10ms 去完成,那么最后一个商品的读请求,可能等待 10
* 100 = 1000ms = 1s 后,才能得到数据,这个时候就导致**读请求的长时阻塞*
*
。
一定要做根据实际业务系统的运行情况,去进行一些压力测试,和模拟线上环境,去看看最繁忙的时候,内存队列可能会挤压多少更新操作,可能会导致最后一个更新操作对应的读请求,会 hang 多少时间,如果读请求在 200ms 返回,如果你计算过后,哪怕是最繁忙的时候,积压 10 个更新操作,最多等待 200ms,那还可以的。
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录