2019-12-18总结：
1、一开始用mysql进行计数，后来加入了主从架构，分库分表架构。
2、因为计数访问量太大了，加入了缓存，但是这个会造成相应的那个缓存和数据库数据不一致，如果要保证一性的话，就需要采用内存队列，对于同一个id的数量只能用单线程进行处理，这个会造成性能问题。
3、后来直接抛弃了mysql，直接用redis cluster来支持计数服务,因为redis通过rdb和aof来支持持久化，可以通过设置保证至少有一台从redis机器同步了数据，从redis来做相应的那个持久化操作达到数据不丢失，因为原生的redis数据结构会占用比较多的字节，这里直接进行改造，让redis的数据结构占用内存加少。
4、但是redis是全内存的，随着量越来越大肯定没法支持了，这里进行改造，引入ssd，支持把冷数据放到ssd中，热数据在内存中，当要访问冷数据时利用一个线程异步把冷数据加载到一个cold cache里面去。这个有很多开源的实现，如Pika，SSDB用ssd来替代内存存储冷数据。展开作者回复: 👍
12
2019-12-18【如果要存储一个 KV 类型的计数信息，Key 是 8 字节 Long 类型的 weibo_id，Value 是 4 字节 int 类型的转发数，存储在 Redis 中之后会占用超过 70 个字节的空间】这个 70 个字节是怎么算出来的，有点懵作者回复: 其实就是redis本身需要的一些存储空间，比如刚才提到的key使用string来存储需要28个字节，redis中使用的类似哈希表的数据结构叫dictEntry，也需要24个字节，还存储一些指针之类
3
2019-12-18通过redis存储计数的话，如果redis机器故障了怎么办呢？微博本身的信息是如何存储的呢，老师能相信讲解下吗作者回复: redis可以做主从，然后从从库恢复数据
1 3
2019-12-26Redis为啥开始不搞long类型的key呢，是为了通用性吗作者回复: 是的
2
2019-12-23老师，这种海量的KV型计数，是否用 hbase存储会好简单许多？起码不用像mysql那样要在client端做分库分表。读请求依然可以走缓存。作者回复: KV型的redis、leveldb之类要比hbase性能好很多，hbase也比较重，要依赖hdfs
2
2019-12-18老师好，想问下用redis的话该怎么用ssd配合做冷热数据存储呢，这块完全没经验，能讲讲具体的实现方案吗？作者回复: 就是需要改造一下redis，如果redis的数据写满了，就将比较旧的数据dump到磁盘上
2
2020-01-04老师，关于关注关系存储，我们公司现在用户的关注列表和粉丝列表都放在redis的sortedset结构中，一个key最大能够占到2g，现在8个节点，每个节点平均已使用20g容量，redis改造的能力我们不具备，还有什么其他优化思路，能够减少存储成本，获取粉丝列表响应时间低延迟呢？作者回复: 粉丝一般只在粉丝列表中展示，现在微博只展示5000个粉丝，所以没必要缓存全量的粉丝数据。
1 1
2019-12-20老师的课虽然代码比较少，但是说实话，实际业务场景里还是能我们不少优化的思路。作者回复: 多谢肯定～
1
2020-01-20老师，通过消息队列来计数的话，怎么保证计数的准确性，比如关注数和粉丝数这种对准确性要求比较高的作者回复: 其实你很难保证写入完全没有错误，一般是对于粉丝数比较少的用户，在获取粉丝数的时候异步从数据库校对一下数据；如果粉丝是比较多，那么差几个用户也不会感觉到😂
2020-01-04打卡。老师，你后面说的需要一个大数组来存储，是不是之前提到的布隆过滤器那种方式？作者回复: 类似吧
2020-01-03请问老师，本文中提到对原生redis组件进行改造，是指的在redis源码上进行改造和定制吗？🤔️😄作者回复: 是的
- 2019-12-31老师，您好，对redis深度改造这块儿没太懂，如：“Key 是 8 字节 Long 类型的 weibo_id，Value 是 4 字节 int 类型的转发数，存储在 Redis 中之后会占用超过 70 个字节的空间”这块儿是怎么计算出来的？
作者回复: 这个主要是参考redis的实现
2019-12-30老师，有个地方没看懂。存数据的时候，我的理解是通过一定的hash把weiboid的位置找到，然后在数组响应的位置存入点赞数。但是在取数据的时候，你加了一个 t[pos]==weibo_id 。你这个t[pos]不是存的点赞数么，怎么又跟weibo_id来判断相不相等呢作者回复: 是这样的，这种方法是为了解决hash冲突的问题，也就是多个weibo_id有可能算出同一个哈希值。所以在存储信息的时候，需要也要存储微博的id，这样才能确定这个位置上到底存储的是哪一个微博ID
- 2019-12-26Pika是不是就是在Redis中改造了下逻辑，把旧的数据dump到SSD上了啊？
作者回复: 类似
- 2019-12-25老师您好 “一是原生的 Redis 在存储 Key 时是按照字符串类型来存储的，比如一个 8 字节的 Long 类型的数据，需要 8（sdshdr 数据结构长度）+ 19（8 字节数字的长度）+1（’\0’）=28 个字节，如果我们使用 Long 类型来存储就只需要 8 个字节，会节省 20 个字节的空间” long类型存储的话不也是 k-v结构吗？
作者回复: 就是要改一下redis的实现，原生的kv的key是string，现在改成long
2019-12-19计数系统如何和业务系统保持一致性？不会少计数，需要核对数据吗？作者回复: 不需要实时比对~
- 2019-12-19redis改造这个还是有点难，redis加SSD做冷热数据分离，这个值得借鉴。
2019-12-18计数器只存id的情况下，如果有按人维度查询的需求怎么办，比如查一定时间获赞数最多的人？作者回复: 这个应该没有办法用计数器解决，计数器只能记录一个人获赞数是多少？
- 2019-12-18老师，请以后多出些专栏，每次看你的专栏都有火花出来
作者回复: 谢谢~
1 - 2019-12-18通过hash来分表，那每次查询的时候也要计算hash值才能知道去查哪张表，性能不会有影响吗？
作者回复: 这还好吧，hash计算基本上微秒级别吧
1