高并发系统设计 40 问
唐扬
美图公司技术专家
49013 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 49 讲
高并发系统设计 40 问
15
15
1.0x
00:00/00:00
登录|注册

37 | 计数系统设计(一):面对海量数据的计数器要如何做?

一课一思
降低计数系统的存储成本
支撑高并发的计数系统设计
计数在业务上的特点
计数系统设计

该思维导图由 AI 生成,仅供参考

你好,我是唐扬。
从今天开始,我们正式进入最后的实战篇。在之前的课程中,我分别从数据库、缓存、消息队列和分布式服务化的角度,带你了解了面对高并发的时候要如何保证系统的高性能、高可用和高可扩展。课程中虽然有大量的例子辅助你理解理论知识,但是没有一个完整的实例帮你把知识串起来。
所以,为了将我们提及的知识落地,在实战篇中,我会以微博为背景,用两个完整的案例带你从实践的角度应对高并发大流量的冲击,期望给你一个更加具体的感性认识,为你在实现类似系统的时候提供一些思路。今天我要讲的第一个案例是如何设计一个支持高并发大存储量的计数系统。
来看这样一个场景: 在地铁上,你也许会经常刷微博、点赞热搜,如果有抽奖活动,再转发一波,而这些与微博息息相关的数据,其实就是微博场景下的计数数据,细说起来,它主要有几类:
微博的评论数、点赞数、转发数、浏览数、表态数等等;
用户的粉丝数、关注数、发布微博数、私信数等等。
微博维度的计数代表了这条微博受欢迎的程度,用户维度的数据(尤其是粉丝数),代表了这个用户的影响力,因此大家会普遍看重这些计数信息。并且在很多场景下,我们都需要查询计数数据(比如首页信息流页面、个人主页面),计数数据访问量巨大,所以需要设计计数系统维护它。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

面对海量数据的计数系统设计是一个重要的技术挑战,尤其在高并发、大数据量和数据强一致性要求的情况下。本文以微博为背景,从业务特点出发,介绍了计数系统设计的演进过程和优化方案。 文章首先指出了计数系统在业务上的特点,包括数据量巨大、访问量大、对性能和准确性要求高等。针对这些特点,文章介绍了微博计数系统的设计和演进。最初采用MySQL存储计数数据,但随着微博规模的扩大,面临了性能损耗的问题,因此引入了分库分表的方式来提升读取计数的性能。随着访问量的飞跃增长,文章还介绍了引入Redis缓存来加速读请求,并且全面使用Redis作为计数的存储组件以保证性能和可用性。此外,为了提升计数的写入性能,文章还提到了使用消息队列来削峰填谷,以及批量处理消息的方式来减小写压力。 通过微博计数系统的设计演进,本文展示了面对海量数据的计数系统的设计和优化方法,对于需要设计类似系统的技术人员具有一定的借鉴意义。文章还介绍了对原生Redis组件的改造,以及使用SSD+内存的方案来最终解决存储计数数据的成本问题。这些优化方案适用于冷热数据明显的场景,并且可以在项目中需要时使用。 总的来说,本文通过微博设计计数系统的例子,展示了在做系统设计时需要了解系统目前的痛点,并针对痛点进行细致的优化。这对读者快速了解面对海量数据的计数系统设计具有一定的参考价值。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《高并发系统设计 40 问》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(46)

  • 最新
  • 精选
  • 台风骆骆
    总结: 1、一开始用mysql进行计数,后来加入了主从架构,分库分表架构。 2、因为计数访问量太大了,加入了缓存,但是这个会造成相应的那个缓存和数据库数据不一致,如果要保证一性的话,就需要采用内存队列,对于同一个id的数量只能用单线程进行处理,这个会造成性能问题。 3、后来直接抛弃了mysql,直接用redis cluster来支持计数服务,因为redis通过rdb和aof来支持持久化,可以通过设置保证至少有一台从redis机器同步了数据,从redis来做相应的那个持久化操作达到数据不丢失,因为原生的redis数据结构会占用比较多的字节,这里直接进行改造,让redis的数据结构占用内存加少。 4、但是redis是全内存的,随着量越来越大肯定没法支持了,这里进行改造,引入ssd,支持把冷数据放到ssd中,热数据在内存中,当要访问冷数据时利用一个线程异步把冷数据加载到一个cold cache里面去。这个有很多开源的实现,如Pika,SSDB用ssd来替代内存存储冷数据。

    作者回复: 👍

    2019-12-18
    3
    62
  • 小困
    微博点赞还有哥难点,就是用户只能点赞一次,这个该用什么存储结构呢,或者技术方案

    作者回复: 布隆过滤器

    2020-05-23
    9
    19
  • bug工程师
    老师,关于关注关系存储,我们公司现在用户的关注列表和粉丝列表都放在redis的sortedset结构中,一个key最大能够占到2g,现在8个节点,每个节点平均已使用20g容量,redis改造的能力我们不具备,还有什么其他优化思路,能够减少存储成本,获取粉丝列表响应时间低延迟呢?

    作者回复: 粉丝一般只在粉丝列表中展示,现在微博只展示5000个粉丝,所以没必要缓存全量的粉丝数据。

    2020-01-04
    3
    14
  • Geek_zhuyu
    老师,通过消息队列来计数的话,怎么保证计数的准确性,比如关注数和粉丝数这种对准确性要求比较高的

    作者回复: 其实你很难保证写入完全没有错误,一般是对于粉丝数比较少的用户,在获取粉丝数的时候异步从数据库校对一下数据;如果粉丝是比较多,那么差几个用户也不会感觉到😂

    2020-01-20
    2
    10
  • 扬一场远远的风
    老师,这种海量的KV型计数,是否用 hbase存储会好简单许多?起码不用像mysql那样要在client端做分库分表。读请求依然可以走缓存。

    作者回复: KV型的redis、leveldb之类要比hbase性能好很多,hbase也比较重,要依赖hdfs

    2019-12-23
    8
  • 吃饭饭
    【如果要存储一个 KV 类型的计数信息,Key 是 8 字节 Long 类型的 weibo_id,Value 是 4 字节 int 类型的转发数,存储在 Redis 中之后会占用超过 70 个字节的空间】这个 70 个字节是怎么算出来的,有点懵

    作者回复: 其实就是redis本身需要的一些存储空间,比如刚才提到的key使用string来存储需要28个字节,redis中使用的类似哈希表的数据结构叫dictEntry,也需要24个字节,还存储一些指针之类

    2019-12-18
    2
    8
  • gogo
    通过redis存储计数的话,如果redis机器故障了怎么办呢?微博本身的信息是如何存储的呢,老师能相信讲解下吗

    作者回复: redis可以做主从,然后从从库恢复数据

    2019-12-18
    4
    7
  • Dovelol
    老师好,想问下用redis的话该怎么用ssd配合做冷热数据存储呢,这块完全没经验,能讲讲具体的实现方案吗?

    作者回复: 就是需要改造一下redis,如果redis的数据写满了,就将比较旧的数据dump到磁盘上

    2019-12-18
    4
    6
  • grandcool
    Redis为啥开始不搞long类型的key呢,是为了通用性吗

    作者回复: 是的

    2019-12-26
    5
  • 星空123
    老师的课虽然代码比较少,但是说实话,实际业务场景里还是能我们不少优化的思路。

    作者回复: 多谢肯定~

    2019-12-20
    4
收起评论
显示
设置
留言
46
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部