这是一个创建于 3657 天前的主题，其中的信息可能已经有所发展或是发生改变。
目前在设计一个用户规模100万的系统，需要设计一个共享缓存并向最少8个节点提供缓存调用接口。打算低成本解决这个问题。
数据持久化不需要，但是高可用必须有，高性能必须有。
单节点要满足10000tps。每10万用户耗内存1G。双机双工负载均衡。读写比率大概是2:8。
一开始我想到的是使用这样的简单架构，后端存储使用redis，前端用tornado多进程负载，达到10000tps没有什么问题。不过redis并不支持双工模式，在应用层解决复制不是很好。
其次想到的是ehcache + bigmemory,性能上还不敢确定，有人测试比redis还牛，还是得自己测试一下才行。ehcache企业版支持分布式模式，没用过。如果使用免费的bigmemory32G，还是得自己解决数据复制问题。
还有什么更好的建议没。
后期扩容200万，我想老板已经赚翻了，上中间件，实时数据库啥的都不是问题了。
数据持久化不需要，但是高可用必须有，高性能必须有。
单节点要满足10000tps。每10万用户耗内存1G。双机双工负载均衡。读写比率大概是2:8。
一开始我想到的是使用这样的简单架构，后端存储使用redis，前端用tornado多进程负载，达到10000tps没有什么问题。不过redis并不支持双工模式，在应用层解决复制不是很好。
其次想到的是ehcache + bigmemory,性能上还不敢确定，有人测试比redis还牛，还是得自己测试一下才行。ehcache企业版支持分布式模式，没用过。如果使用免费的bigmemory32G，还是得自己解决数据复制问题。
还有什么更好的建议没。
后期扩容200万，我想老板已经赚翻了，上中间件，实时数据库啥的都不是问题了。
第 1 条附言 · 2014-11-27 10:35:53 +08:00
经过一番考虑，我打算放弃共享缓存这种模式了，
计划用mysql数据库集群来解决这个问题，在双机mysql HA的基础上挂一群只读节点来提供最少8个节点的数据读取操作。写操作直接入主库无压力。
看起来这是最简单地方案了，应用层一下子简单了。200万，300万随便扩了。
另外还有一个在线用户缓存，按70%在线率，100万用户需要2G内存，那就直接在jvm堆内做了，分布在各个节点全无压力。
好了，我现在开始需求一个DBA了。
计划用mysql数据库集群来解决这个问题，在双机mysql HA的基础上挂一群只读节点来提供最少8个节点的数据读取操作。写操作直接入主库无压力。
看起来这是最简单地方案了，应用层一下子简单了。200万，300万随便扩了。
另外还有一个在线用户缓存，按70%在线率，100万用户需要2G内存，那就直接在jvm堆内做了，分布在各个节点全无压力。
好了，我现在开始需求一个DBA了。
 |
1
feilaoda 2014-11-26 21:28:41 +08:00
Redis还是比较稳定的，双机双工是否必要？一定要的话，看看Twemproxy。
|
 |
4
c4pt0r 2014-11-27 10:43:59 +08:00
codis 可以试试
|
|
11
c4pt0r 2014-11-28 12:03:31 +08:00
@feilaoda 目前我司所有的 redis 服务都已经在 codis 上稳定运行了. 总的集群规模大概 2T 的内存左右. 因为不少业务是完全拿 redis 当存储用, 只有写的请求打到数据库或者 HBase 上, 还有些业务是通过 MapReduce 过程直接生成数据灌进 Redis 里, 读请求全部走 Redis, 所以基本不能容忍缓存 miss, 或者触发 LRU, 而且需要不中断服务的迁移和扩容, 而且还不能有单点, 否则单机的网卡抗不住. 所以, Codis 是在这个背景下开发的. 不知道你的场景如何.
|
|
12
feilaoda 2014-11-28 14:04:06 +08:00
@c4pt0r 主要是实时计算的结果数据，需要保存在redis中，数据还不少，写redis的要求会比较高，当然，读和写差不多多。读/写大概分别需要200000tps。
|
|
13
c4pt0r 2014-11-28 15:31:16 +08:00
codis 不是为这个设计的, 不过抛开数据大小, 机器配置谈 tps 不太合适. 我这里有一个 benchmark 的文档, 可以参考下: https://github.com/wandoulabs/codis/blob/master/doc/benchmark_zh.md
|
 |
15
jamiesun OP |
Select Language