社区
Java EE
帖子详情
memcache ,redis所能支持的最大并发量
piaopiao11
2016-08-22 08:08:56
网上搜了下redis的测试报告,redis可以支持6W+ 小数据可以达到10W的并发,而memcache单台只能支持5K以下的并发,不是说memcache的并发量要大于redis的,memcache的效率高于redis应该,所以哪位能告诉我单台memcache/redis最大并发量各有多少,10台集群部署大概又有多少呢
...全文
2938
2
打赏
收藏
memcache ,redis所能支持的最大并发量
网上搜了下redis的测试报告,redis可以支持6W+ 小数据可以达到10W的并发,而memcache单台只能支持5K以下的并发,不是说memcache的并发量要大于redis的,memcache的效率高于redis应该,所以哪位能告诉我单台memcache/redis最大并发量各有多少,10台集群部署大概又有多少呢
复制链接
扫一扫
分享
转发到动态
举报
写回复
配置赞助广告
用AI写文章
2 条
回复
切换为时间正序
请发表友善的回复…
发表回复
打赏红包
执笔记忆的空白
2016-08-24
打赏
举报
回复
不会吧,两者应该差距不大才对
yctang
2016-08-23
打赏
举报
回复
这种测试数据网上有,http://blog.sina.com.cn/s/blog_6145ed810102vefe.html 或者你可以自己搭建环境测 我们一般都用redis,没有使用memcache
mem
cache
与
redis
的比较
简单的比较了两者的异同,方便读者的认识!
如何利用
Redis
锁解决高
并发
问题详解
redis
技术的使用:
redis
真的是一个很好的技术,它可以很好的在一定程度上解决网站一瞬间的
并发
量
,例如商品抢购秒杀等活动。。。
redis
之所以能解决高
并发
的原因是它可以直接访问内存,而以往我们用的是数据库(硬盘),提高了访问效率,解决了数据库服务器压力。 为什么
redis
的地位越来越高,我们为何不选择
mem
cache
,这是因为
mem
cache
只能存储字符串,而
redis
存储类型很丰富(例如有字符串、LIST、SET等),
mem
cache
每个值
最大
只能存储1M,存储资源非常有限,十分消耗内存资源,而
redis
可以存储1G,最重要的是
mem
cache
它不如
redis
安全,当服务器发生故障
Redis
锁解决高
并发
问题
Redis
锁解决高
并发
问题
redis
真的是一个很好的技术,它可以很好的在一定程度上解决网站一瞬间的
并发
量
,例如商品抢购秒杀等活动。
redis
之所以能解决高
并发
的原因是它可以直接访问内存,而以往我们用的是数据库(硬盘),提高了访问效率,解决了数据库服务器压力。 为什么
redis
的地位越来越高,我们为何不选择
mem
cache
,这是因为
mem
cache
只能存储字符串,而
redis
存储类型很丰富(例如有字符串、LIST、SET等),
mem
cache
每个值
最大
只能存储1M,存储资源非常有限,十分消耗内存资源。 而
Redis
(十)
redis
使用list解决高
并发
问题,如商品秒杀
redis
真的是一个很好的技术,它可以很好的在一定程度上解决网站一瞬间的
并发
量
,例如商品抢购秒杀等活动。
redis
之所以能解决高
并发
的原因是它可以直接访问内存,而以往我们用的是数据库(硬盘),提高了访问效率,解决了数据库服务器压力。 为什么
redis
的地位越来越高,我们为何不选择
mem
cache
,这是因为
mem
cache
只能存储字符串,而
redis
存储类型很丰富(例如有字符串、LIST、SET等),
mem
cache
每个值
最大
只能存储1M,存储资源非常有限,十分消耗内存资源,而
redis
可以存储1G,最重要
Redis
高
并发
问题,及解决方案!
(一)
redis
技术的使用:
redis
真的是一个很好的技术,它可以很好的在一定程度上解决网站一瞬间的
并发
量
,例如商品抢购秒杀等活动。。。
redis
之所以能解决高
并发
的原因是它可以直接访问内存,而以往我们用的是数据库(硬盘),提高了访问效率,解决了数据库服务器压力。 为什么
redis
的地位越来越高,我们为何不选择
mem
cache
,这是因为
mem
cache
只能存储字符串,而
redis
存储类型...
Java EE
67,512
社区成员
225,881
社区内容
发帖
与我相关
我的任务
Java EE
J2EE只是Java企业应用。我们需要一个跨J2SE/WEB/EJB的微容器,保护我们的业务核心组件(中间件),以延续它的生命力,而不是依赖J2SE/J2EE版本。
复制链接
扫一扫
分享
社区描述
J2EE只是Java企业应用。我们需要一个跨J2SE/WEB/EJB的微容器,保护我们的业务核心组件(中间件),以延续它的生命力,而不是依赖J2SE/J2EE版本。
社区管理员
加入社区
获取链接或二维码
近7日
近30日
至今
加载中
查看更多榜单
社区公告
暂无公告
试试用AI创作助手写篇文章吧
+ 用AI写文章