新浪微博Redis应用实践
Redis(http://redis.io/)是一个key-
新浪大量使用Redis、其中一个重要使用场景是计数器、
在新浪微博如此海量的数据和高并发场景(
Offer这边也有很多使用数字的场景:如重发的400限制条数
当前是采用MC(memcached)+Mysql的方式、但M
而使用Redis可以很好的解决这些问题。
eBay技术平台
同为B2B站点、发现Ebay的技术架构和我们有不少的共同点、
eBay的一些数据
1、数据总存储量达到9P
2、10000台应用服务器
3、4400万行代码
4、20亿张图片
5、可用性99.94%
架构特点:
1、数据库、应用层、搜索引擎等都进行了拆分、保证可扩展性
2、应用间的Session无状态化(类似于Session服务
3、在容错和监控方面:有Logging中心、Mark downs(自动发现哪些应用不可用、
4、服务化大规模使用(但主要采用Webservice的方式、
面临的挑战和一些解决方案:
1、代码业务逻辑太复杂(4400万行代码、4000多个Jar
OSGi模块化、封装内部逻辑、
2、服务的数据格式很多、服务(Webservice)
将各种数据格式统一转换成JAXB、采用二进制格式(Go
3、服务调用中的N+1问题、服务返回数据利用率问题(
自主开发了ql.io(即将开源)、能够像写SQL那样调用
大众点评网的技术变迁之路
总体讲的都是通用的技术、Memcached的使用经验方面讲的
1、缓存对象粒度的控制、便于缓存的更新删除
有时需要缓存一个列表、
改进的方式是:比如原来是缓存List<Shop>、
好处是每个Shop对象本身可以直接通过缓存读取、当单个Sho
Mget()可以一次性获取整个列表
2、大批量缓存的清除
如果缓存的数据格式变化较大时、为了防止缓存的脏数据问题;
如果缓存的数据大体跟原来相同、只是某个字段变化的话可以采用给
自动管理Key的版本号、避免了开发自己去维护版本号
3、缓存序列化和反序列化对CPU和网络的开销
可以采用一些相对高效的数据交换格式如Google Protocol Buffer(空间利用率和序列化性能比XML、Json、Ja
4、多Memcached服务器下的分布式算法
采用业界通用的一致性哈希算法(我们还用模取余的方式、
5、在数据访问层DAO实现自动缓存
通过AOP来实现、确实很多时候只是缓存DAO层返回的对象、
6、缓存雪崩问题
指的是缓存大量失效导致DB负载瞬间上升的问题(
后面准备采用Redis来替代Memcached也解决这个问题