这是一个创建于 3138 天前的主题，其中的信息可能已经有所发展或是发生改变。
前段时间在 V2EX 上请教过这个实现的一些方案
链接
https://v2ex.com/t/236160#reply17
问题前景可以描述如下：
有 100 个产品，需要知道每个产品最近 60 秒的每秒请求负载数，并且可以看全国 400 个主要城市下以及华北，华东等聚合大区的负载指标。
分产品和城市储存的话 400*100 = 4w 个 k/v 数据 每秒写入 4w 条数据，对于任何数据库都是非常有挑战的 （放弃）
分产品存储，把同一时间戳各个大区和城市的指标聚成一条记录： 400 条每秒的记录量，数据库写入毫无压力。
为什么放弃 list 或者 有序集合， 因为需要多余的机制保证删除过期的数据，而使用 redis 过期 k/v 存储策略 （ 120 秒过期）能更好完成这项需求实现。（这些数据也会实时落地插入到 mysql 等备份）。
当展示最近 60 秒的数据时，我们发现可以在服务层缓存使用前 59 秒从 redis 已经拉取的数据。所以只要在服务后端加上一个内部缓存就可以加速数据的前端展示，因为后面的前端发请求带上时间戳，只要给时间戳后到现在时间几秒的数据（主要考虑到用户的网络延迟，大多数时间都是下一秒的数据）。最后当用户首次打开前端时，在网络正常的情况下，展示 60 秒数据也不到 0.03s 。 已经很好的满足用户的刷屏感。
核心部分还是服务内部缓存，其实如果使用数据直接存 mysql 在比较少用户时同样可以达到每秒刷新展示性能，但因为考虑到高峰期负载问题，所以使用 redis.
链接
https://v2ex.com/t/236160#reply17
问题前景可以描述如下：
有 100 个产品，需要知道每个产品最近 60 秒的每秒请求负载数，并且可以看全国 400 个主要城市下以及华北，华东等聚合大区的负载指标。
分产品和城市储存的话 400*100 = 4w 个 k/v 数据 每秒写入 4w 条数据，对于任何数据库都是非常有挑战的 （放弃）
分产品存储，把同一时间戳各个大区和城市的指标聚成一条记录： 400 条每秒的记录量，数据库写入毫无压力。
为什么放弃 list 或者 有序集合， 因为需要多余的机制保证删除过期的数据，而使用 redis 过期 k/v 存储策略 （ 120 秒过期）能更好完成这项需求实现。（这些数据也会实时落地插入到 mysql 等备份）。
当展示最近 60 秒的数据时，我们发现可以在服务层缓存使用前 59 秒从 redis 已经拉取的数据。所以只要在服务后端加上一个内部缓存就可以加速数据的前端展示，因为后面的前端发请求带上时间戳，只要给时间戳后到现在时间几秒的数据（主要考虑到用户的网络延迟，大多数时间都是下一秒的数据）。最后当用户首次打开前端时，在网络正常的情况下，展示 60 秒数据也不到 0.03s 。 已经很好的满足用户的刷屏感。
核心部分还是服务内部缓存，其实如果使用数据直接存 mysql 在比较少用户时同样可以达到每秒刷新展示性能，但因为考虑到高峰期负载问题，所以使用 redis.
目前尚无回复
Select Language