最近在开发一个在线视频网站，有几个关于 redis 问题请教。

[odoooo]

类似 youtube 的网站，网站使用 redis 主从+mysql 主从方式。

大概的结构思路是这样的。

1 ，

用户-->读--->redis 从--->(如果不存在，存在返回结果|结束|，不存在返回 0|继续下一步|)--->读 Mysql 从--->（存在返回结果，不存在返回 0 ，结束）

用户-->写--->写 Mysql 主--->写 redis 主--->结束。

大家看我这种设计方法可行不，有什么弊端和建议。

PS ：视频点击量以及顶踩等热数据直接使用 redis ，一天 crontab 一次到 mysql 里。

[odoooo]

希望各位大神不吝赐教，在此谢谢诸位！！

[baskice]

用户-->写--->写 Mysql 主

这步多半会崩， Wikipedia 写频率不高都不敢直接写主 database ，建议写到 redis 从，然后定时写入数据库（数据量上去之后就会变成队列持续写入了）。可以给用户显示视频正在处理中，并不需要实时处理完

[odoooo]

@baskice 谢谢解答，其实我希望直接写入到 redis 主中，然后再同步到 MySQL 主中，但是不知道有什么稳定成熟一点的方案，能使 Redis 主和 Mysql 主实时同步。（我这个系统，主从和项目是互通的所以，想将读全分给从，写全分给主。）

[sudoz]

@baskice 从 redis 同步到 sql 的方案有什么最佳实践吗？

[lecher]

播放次数这种高频词又不一定要去完全准确的计数的值，可以先写入 Redis 主，同时 Redis 主开一个 key 设写入记录时间，记录的时候判断是否需要到时间写入 MySQL ，定时刷入 MySQL 主。

其它频次不高的持久化数据，视频内容，评论一类的，直接写入 MySQL 主也可以，至于是否要刷新 Redis 主，看关联数据是不是很多，如果写入一个记录要更新几十个关联的 Redis 记录，不如考虑一下 Redis 那边缓存数据的时间做做限制，由外部请求触发 Redis 定时更新。

非要保证实时性和一致性的，前期业务量不大可以写入 MySQL 主，更新 Redis 主这样走。如果业务量很大，数据就在 Redis 上面转了，数据读写都在 Redis 上，直接写入 Redis 主，同时后台开进程专门做把 Redis 刷入 MySQL 的任务。
要想保证 Redis 和 MySQL 一致，那负载就只能以低的为主，等于牺牲 Redis 的写入速度，要想利用 Redis 的写入和读取的高负载，就必须承担数据丢失的风险，分时间段异步写入 MySQL ，这点可以通过同局域网内写两个 Redis 来减少一点风险，不过就复杂很多。

[odoooo]

@lecher 说了这么多，对我很有帮助，太感谢你了。视频分类以及列表查询结果结果也打算序列化到 redis ，设置个超时时间，这样的话前期基本没什么问题了。

[slixurd]

对于这种数据记在内存里面真的好么，还是 Redis 这种持久化烂的不行几乎不实用的中间件
至少在我看来这是不切实际的，虽然这些数据实时性要求很低，但是不代表它的稳定性不需要保证
所以最好用持久化有保证的消息队列 /NoSQL 来储存这些数据，隔一定间隔再刷入数据库，而且不需要一天一次，一天多次完全没啥问题。
保持数据一致性很重要，尤其是在分布式的环境下。

[zaishanfeng]

多少用户量 切记过度设计 买点大点的服务器 做好备份就行了

[sujin190]

@baskice 这样数据一致性要疯的， mysql 写入性能也没差到这种地步，还是看写入频次和写入量吧，频次高量大的准确性要求一般来说会低一些，比如浏览次数播放次数，视屏上传，评论之类的哪有那么高的频次和量，但准确性要求就高了很多， mysql 直接写完全没事

[tonghuashuai]

1. 用户读，如果 redis 不存在 mysql 存在的情况下，在 mysql 读出后最好写到 redis 一份吧
2. 既然有定时同步为何不直接向 主 redis 写，没必要向 redis 和 mysql 都写一份吧。看数据量和频次了，如果都很小的话可以直接向 redis 写，这样就不存在 第一步中的 redis 不存在， mysql 存在的情况了。

同意 @zaishanfeng 的说法，不要过度设计，如果现阶段没有这么大的压力可以先做最小可行性，按照先抗住再优化的原则后期快速迭代来应对数据量的增长