微博数据库设计

Ⅰ 新浪微博“点赞功能”数据库如何设计的

新浪微博“点赞功能”的数据库设计主要基于以下几点：

1. 数据分离存储：

   • 每个微博的内容与对应的点赞数被分别存储，这种设计确保了信息的清晰性和高效管理。微博内容可能存储在关系型数据库中，而点赞数则采用更适合高并发读写操作的存储方案。

2. 基于Redis的二次开发计数器：

   • 微博点赞功能利用基于Redis的二次开发计数器进行数据存储。Redis以其高效存储和优化性能的特性，非常适合处理这种高并发的读写操作。
   • 在存储资源管理方面，系统充分利用内存资源，并在接近存储极限时，自动将最古老的数据转移至磁盘，以确保数据的连续性和完整性。

3. 缓存与磁盘数据的协同工作：

   • 当在Redis缓存中未能找到所需数据时，系统会读取磁盘数据。但通常这种情况只涉及最旧的数据，因此对系统性能的影响微乎其微。
   • 此设计与原生Redis性能保持一致，但能在相同内存条件下存储更多数据，提高了存储效率。

4. 开源计数器代码计划：

   • 新浪微博有计划将计数器相关的开源代码提供给有需要的用户，这有助于其他开发者理解和实现类似的功能。

5. 借鉴前辈经验与深入学习：

   • 在设计与优化计数器功能方面，新浪微博借鉴了前辈的经验，并通过阅读相关文章来提升对计数器设计的理解和实践能力。

综上所述，新浪微博的“点赞功能”数据库设计采用了高效的数据分离存储策略，利用Redis进行高并发读写操作，并通过缓存与磁盘数据的协同工作确保数据的完整性和性能。同时，新浪微博还计划开源相关代码，并鼓励开发者借鉴前辈经验进行深入学习。

Ⅱ 新浪微博“点赞功能”数据库如何设计的

对于第一个问题，设计一个schema->(messageID，likedCount)，记录每条微博的点赞数。messageID是微博的编号，likedCount是该微博的点赞人数。但是这里有两个问题需要解决，第一是并发，第二是数据量。

每条微博都有可能有很多人同时点赞，为了保证点赞人数精确就需要保证likedCount++是原子操作，这个可以由应用程序来实现，也可以用redis的事务来实现(如果redis有事务机制或者自增功能的话)，但是我觉得为了性能考虑，也可以不用实现原子操作，具体原因就不展开了。

每天都上亿可能更多的微博内容产生，这样就会有上亿个新的(messageID，likedCount)生成，这样的数据量是比较大的，单机数据库比较难提供高效的服务，所以需要采取sharding的功能(有时候也叫分表分库)，可能根据messageID把这些schema分散到十个或者更多的shards上(据说，sina微博有600个节点，如何三个节点组成一个shard，就有200个shards)，这样每个shard处理的请求就只有原来的十分之一，从而就能提高服务的性能。

关于点赞人列表的设计，一般来说，可能想到的schema是(messageID，userID)，但是这样的设计有一个小问题，就是有些大发的微博可能会得到几十万的点赞，这样就会产生几十万个条数据，这样数据有点多，读取起来可能也慢。所以可以用这样一个schema(messageID，partID，userIDs)，让一个messageID对于多个userID，同时比对应太多的userID，所以加入一个新的partID，一个part存1000个userID，这样几十万个点赞，只需要存几百条数据。这样做还有一个好处，用户点击查看点赞人时的，一般都不是完全显示所有点赞人，而是一批一批显示，这样可以一次只读一条数据，就可显示一批点赞用户信息。

Ⅲ 微博如何使用大数据存储技术

Mongodb和Redis，Mongodb可以满足大量数据的存储，Redis是内存数据库，适合Key-Value形式的快速读写，适合做缓存，占用内存资源多，不适合存储大量数据。

微博是近几年发展得极为火热的信息发布和分享平台，可以发布微博、分享信息、评论和参与话题的讨论。为了让用户及时了解到最热门的话题、最热门的信息。

需要对微博系统中的数据进行实时处理和分析。而Storm是一个免费开源、分布式的、具有很好容错性的实时计算系统，通过Storm可以实时处理微博系统中的数据，并根据处理结果向用户进行实时热门推送。

微博大数据：

微博其实和淘宝是很类似的。一般来说，第一代架构，基本上能支撑到用户到 百万 级别，到第二代架构基本能支撑到 千万 级别都没什么问题，当业务规模到 亿级别时，需要第三代的架构。

从LAMP的架构到面向服务的架构，有几个地方是非常难的，首先不可能在第一代基础上通过简单的修修补补满足用户量快速增长的，同时线上业务又不能停，这是我们常说的在飞机上换引擎的问题。

建议在做服务化的时候，首先更多是偏向业务的梳理，同时要找准一个很好的切入点，既有架构和服务化上的提升，业务方也要有收益，比如提升性能或者降低维护成本同时升级过程要平滑，建议开始从原子化服务切入，比如基础的用户服务， 基础的短消息服务，基础的推送服务。

第二，就是可 以做无状态服 务，后面会详细讲，还有数据量大了后需要做数据Sharding，后面会将。第三代 架构 要解决的 问题，就是用户量和业务趋于稳步增加（相对爆发期的指数级增长），更多考虑技术框架的稳定性， 提升系统整体的性能，降低成本，还有对整个系统监控的完善和升级。

Ⅳ 微博的系统架构，想用mysql+redis配合使用，想问一下具体要怎么操作

微博的系统架构，想用mysql+redis配合使用，具体操作步骤：
写入数据到Redis,，然后在写个运行cron的脚本，美妙搏游读内存，并写入数据库即可。
使用注意：
1、MySQL使用需要注意的地方：
1) 、存储引擎选择InnoDB，在高并发下读写有很好的表现；
2)、 数据合理分表分区，均衡各数据库服务器的负载；
3) 、适当作数据的冗余，便于在cache失效时的快速恢复；
2、Redis使用需要注意的地方：
1) 、合理规划cache；
将访问量高的热点数据统计出来、分类稿键缓基敬销存。
2)、 缓存的压缩；
在高访问量和高并发下，每一个字节的减少都是巨大的节省。
3、数据实时性与一致性。