数据库设计

简介：

本项目是一个视频点播服务端，主要有发视频，关注，点赞，评论，举报，消息推送等难点。

前提：

1、 项目有100万个视频源，1000万的用户量；
2、 使用mysql5.7，单库，无主从；
3、 服务器配置为4核20G内存8G硬盘；
目标：
使用上述的数据库与服务器，实现类似抖音的服务端，推送时并发每秒10000左右。

难点一：

关注、点赞、举报与评论的数据库设计。一千万的用户量，平均有百分之一约10万的用户两两之间进行关注，数据量是100亿，即使使用mysql的分表功能也是非常恐怖的事情。后来决定使用redis的位图功能来存储，每个用户都维护一张位图，需要1000000/(8*1024)=122MB的内存空间，10万的用户就是11920GB的内存。

难点二：

消息推送的数据库设计。当有新视频发布，则向粉丝们推送消息。如果所有的消息存储在一张表中，存储数据直线上升，无法持久，即使分表也难以长久。后来决定使用redis来存储，每个用户维护一个list链表，当用户粉丝数有1万时，就要向1万个链表里循环插入消息，当用户一起上传视频，高并发的时候，redis插入操作会是一个很耗时的事情。

1000万的用户量，难道还请不起一个架构师么？花5C币就搞定了？感觉你们老板好抠啊。

我感觉你们项目最大的难点就是缺钱。因为缺钱，所以请不起程序员，“发视频，关注，点赞，评论，举报，消息推送”，我觉得个个都是难点。

1000万的用户量，你的服务器居然还是我自己个人电脑内存的零头，我电脑还128GB内存呢。看不出来，我的个人电脑能承载一个省的用户？

抖音的老总，会爆发的。。。留一个程序猿即可，其它的瞬间炒鱿鱼！！！

都别墨迹了，5c币只是楼主抛砖引玉，各位都痛快的报价吧，公平竞标

这种核心问题需要来网络上沟通的小项目不要想太多，提问者对并发每秒10000左右有没有个谱？ 一个视频客户端能有1000并发，就已经是非常非常成功的案例了，那时候就已经不差钱去挖两个抖音的架构。所以我的建议，上面的指标都可以看做是远景规划扔垃圾桶里，系统按1000活跃用户、100并发去设计，项目真正有起色了重做都来得及，否则会被这个架构的成本和复杂度拖累。

看了下你的这个需求，总结下。问题1.存储问题，问题2.并发问题。
问题一 来看，全用redis，不现实，成本太高，毕竟存在冷热数据的问题。推荐解决方案，MySQL分表存全量数据，redis 存缓存数据。理解你们的这个项目日活用户并不会太高。内存最起码生出100倍以上，等你日活上了10w已经有条件重构了
问题二来看，是并发问题。常见的解决方案，削峰、分流、合并。削峰做简单，推荐个消息队列nsq，git上搜下就行。分流和合并请求需要架构调整，等后面有条件在做就行
另外你的这个计算方式有问题，关注用户其实一般并不高，平均10个左右已经算多的了，数据量1亿左右就差不错了，除非你这个项目强烈依赖社交关系。
分表需要注意散列，单表数据不要超过 1000w，索引性能问题，也要注意索引的建立，防止索引占用空间过大。