更新时间:2024-01-04 GMT+08:00

典型应用场景

Redis应用场景

很多大型电商网站、视频直播和游戏应用等,存在大规模数据访问,对数据查询效率要求高,且数据结构简单不涉及太多关联查询。这种场景使用Redis,在速度上对传统磁盘数据库有很大优势,能够有效减少数据库磁盘IO,提高数据查询效率,减轻管理维护工作量,降低数据库存储成本。Redis对传统磁盘数据库是一个重要的补充,成为了互联网应用,尤其是支持高并发访问的互联网应用必不可少的基础服务之一。

以下举几个典型样例:

  1. (电商网站秒杀抢购

    电商网站的商品类目、推荐系统以及秒杀抢购活动,适宜使用Redis缓存数据库。

    例如秒杀抢购活动,并发高,对于传统关系型数据库来说访问压力大,需要较高的硬件配置(如磁盘IO)支撑。Redis数据库,单节点QPS支撑能达到10万,轻松应对秒杀并发。实现秒杀和数据加锁的命令简单,使用SET、GET、DEL、RPUSH等命令即可。

    加锁部分,可参考最佳实践:使用DCS实现分布式锁

  2. (视频直播消息弹幕

    直播间的在线用户列表,礼物排行榜,弹幕消息等信息,都适合使用Redis中的SortedSet结构进行存储。

    例如弹幕消息,可使用ZREVRANGEBYSCORE排序返回,在Redis 5.0中,新增了zpopmax,zpopmin命令,更加方便消息处理。

  3. (游戏应用游戏排行榜

    在线游戏一般涉及排行榜实时展现,比如列出当前得分最高的10个用户。使用Redis的有序集合存储用户排行榜非常合适,有序集合使用非常简单,提供多达20个操作集合的命令。

    可参考最佳实践:使用DCS实现排行榜功能

  4. (社交APP)返回最新评论/回复

    在web类应用中,常有“最新评论”之类的查询,如果使用关系型数据库,往往涉及到按评论时间逆排序,随着评论越来越多,排序效率越来越低,且并发频繁。

    使用Redis的List(链表),例如存储最新1000条评论,当请求的评论数在这个范围,就不需要访问磁盘数据库,直接从缓存中返回,减少数据库压力的同时,提升APP的响应速度。

Memcached(已停售)典型应用场景

Memcached主要存储字符串类的简单key-value数据。

  1. 静态页面缓存。

    Web页面的内容片段,包括HTML,CSS和图片等静态数据,内容修改操作少,读取频繁,可以缓存到DCS Memcached实例,提高网站的访问性能。

  2. 数据库前端缓存。

    在动态系统中存在对大量数据读多写少的场景,如社交、博客网站大量查询用户信息、好友信息、文章信息等。为了减少磁盘数据库负载,提升性能,这些经常需要从数据库读取的数据,可以缓存在Memcached中。

    适宜缓存的数据主要有:

    • 经常被读取,实时性要求不高,且可以自动过期的数据。

      例如网站首页最新文章列表、某某排行等数据,虽然新数据不断产生,但对用户体验影响比较小。这类数据可使用典型的缓存策略,设置合理的过期时间,当数据过期以后再从数据库中读取。为了让编辑或者其它人员能马上看到效果,可以再定一个缓存清除/刷新策略。

    • 经常被读取并且实时性要求强的数据。

      比如用户的好友列表,用户文章列表,用户阅读记录等。这类数据首先被载入到Memcached中,当发生更改(添加、修改、删除)时就刷新缓存数据。

  3. 秒杀功能。

    商品下单操作,牵涉数据库读取,写入订单,更改库存,及事务一致性要求, 对于使用传统型数据库的平台来说,秒杀活动阶段要避免订单创建后库存缺货,同时提供流畅的用户体验,压力巨大。

    可以利用Memcached的incr/decr功能, 在内存中存储商品的库存量, 秒杀的抢单过程主要在内存中完成,速度非常快,抢单成功即得一个订单号,这时再去支付页面完成订单的后续操作。

不适用Memcached的应用场景:

  • 单个缓存对象大于1M

    Memcached单个缓存对象的value值不能超过1M。超过1M的场景,建议使用Redis。

  • Key的长度大于250字符

    如确需使用Memcached,可将key先进行md5,得到散列值,然后存储key对应的散列值。

  • 业务需要保证数据高可靠

    开源Memcached不支持持久化数据,无法存副本、备份以及数据迁移。

    注意:DCS的Memcached主备版本实现了数据持久化,具体可联系技术支持。

  • 对数据结构和处理有高级要求

    Memcached只支持key-value简单结构,不支持链表、集合等高级数据结构以及排序等一系列复杂操作。