下载文档原格式
新浪微博分析微博又叫微博客 (micro blog)，是微型博客的简称，基于web2.0技术的即时信息发布系统。
是一个基于用户关系的信息分享、传播以及获取平台，用户可以通过WEB、WAP以及各种客户端组件个人社区，以140字左右的文字更新信息，并实现即时分享。
与传统博客相比，以“短、灵、快”为特点。
140字左右的文字更新信息，并实现即时分享。
微型博客可分为两大市场，一类是定位于个人用户的微型博客，另外一类是定位于企业客户的微型博客。
微博客是信息日益碎片化的必然结果。
“围脖”是微博客的谐音，所以微博也称围脖。
微博客的代表性网站是美国的Twitter，是最早也是最著名的微博，这个词甚至已经成为了微博客的代名词。
新浪作为中国最大的门户网站之一，2009年八月新浪推出新浪微薄测试版，成为门户网站第一家提供微薄服务的网站，微薄正式进入中文上网人群视野！一、新浪微薄发展背景Web2.0时代。
新的媒体形态层出不穷，每一个新媒体形式的出现都意味着Web2.0的普及和网络的进步。
进入2010年，Web2.0更是狂飙突进，中国网民的参与度和活跃呈现爆炸式增长，这一情况的出现，与一种新媒体形态的诞生不无关系—微博。
网络与传统的博客相比，微博发布更便利、传播更迅速，发布字数限制在140字之内，方便用户通过电脑、手机等多平台浏览发布，所发布信息是传达，并可一键转发。
微博相比传统博客那种需要考虑文题、组织语言修辞来叙述的长篇大论，以“短、灵、快”为特点的“微博”几乎不需要很高成本，无论你是用电脑还是手机，只需三言两语，就可记录下自己某刻的心情、某一瞬的感悟，或者某条可供分享和收藏的信息，这样的即时表述显然更加迎合我们快节奏的生活。
微博微博客草根性更强，且广泛分布在桌面、浏览器、移动终端等多个平台上，有多种商业模式并存，或形成多个垂直细分领域的可能。
微博更符合现在人的生活节奏和习惯。
而新技术的运用使得用户更容易对访问者者留言进行回复，从而形成良好的互动关系。
微博平台护城河构建高效的防御体系@王关胜大纲微博平台业务介绍平台防御体系框架设计平台层实践新浪故障管理小结&QA1.微博平台业务介绍用户8亿注册用户8000万+DAU 1.75亿MAU系统200+集群3000+设备日均6百亿Hits运维99.99%Docker：53%变更：15次/周2.面临的挑战●产品功能迭代快，系统变更及代码上线次数多●突发的热点事件#周一见##且行切珍惜##马航370##刘翔摔倒#●每日不定时段的Push内容●业务上复杂的依赖关系●基于微博的大型运营活动：让红包飞，随手拍…●每年一度的三节保障&春晚大考3.突发流量峰值●热门事件：最大30倍瞬间峰值◆微博，转发，评论，赞◆长微博◆话题●典型案例：日常Push◆落地页：业务模块，如话题，热门微博◆下发速度：快，中，慢◆用户模型：全量，高中低频，地区，灰度模型（如尾号）◆用户互动时间：<1h◆分类：应用内Push，应用外Push，运营及活动Push大纲微博平台业务介绍平台防御体系框架设计平台层实践新浪故障管理小结&QA1.什么是防御体系架构容量监控干预实时性&报警快误报少&报警准无遗漏&覆盖全防御体系四要素性能好&冗余够快速动态扩容压测&容量预警极简的架构稳健的架构美丽的架构预案全&手段多操作快&方案细干预行之有效.快.全.准.简.美.稳.多.效.细.够.警.动2.防御体系框架四层七层Web RPCProcessor 规范业务日志Http MC(Q)资源层MySQL Redis Hbase 平台架构运维四化建设全链路SLA 运维数据接口分工&职责&KPI 标准流程规范监控容量架构干预定期巡检&演练7x24小时轮班定期培训知识管理防御标准化防御制度服务隔离快速失败大纲微博平台业务介绍平台防御体系框架设计平台层实践新浪故障管理小结&QA1.防御架构设计之防单点●防单点◆调用链路上避免单点无状态：前端，队列处理，RPC 支持503机制◆线性扩容，平滑上下线，在线调整业务代码层支持，运维只需改配置◆核心资源设计为分层访问缓存分级10G 10G 10G 10G Maste r 10G10G10G10GSlaveWebL1L1L1L1DB(1)select one of L1 cache （include master ）,get from it(2) if L1 exist,return;if not exist,get from master.(3) if master exist, return, and set L1; else if not exist, get from slave(4) if slave exist, return,set master and L1;else if not exist,get from db(5) if db exist,return,set master,slave and L1;else throw exception(6)if has new data (mcq process),update all of L1,master, slave访问逻辑防御架构设计之隔离●隔离：80-20原则◆业务层：基于SLA的快速失败代码分层与服务化异步解耦合◆部署层：核心链路独立部署多机房容灾◆基础架构层：核心服务设备网络层隔离交换机上联容灾微博平台部署架构多机房部署核心服务独立域名，上下行分开七层独立部署核心服务独立服务池Tomcat线程保护快速失败服务化及独立部署核心资源独立部署外部依赖异步解耦隔离方法防御架构设计之多机房实践多机房组件●核心问题◆机房间延时：用户的请求应该在本机房内完成◆专线质量◆部署范围：核心业务路径本地部署依赖业务数据同步◆数据异地多写：部署业务消息化多机房同步组件（MytriggerQ，WMB）◆七层规则：非核心路径穿透北京◆数据一致性◆配置基础设施◆技术改造对线上业务的影响2.主动防御-监控体系新浪综合运维平台SinaWatchJpool_agentLogtailer SinaScri pt基础资源应用程序业务监控运维数据load cpu memswapNet disk inodepingIo proc threadtcp_c Message cs pgmf端口监控线程Jvm & GC Nginx 状态资源线程池&分布耗时接口稳定性（99.95%）Profile &WatchMan 集群单机健康状态部署层数据业务层数据资源层数据核心模块数据Diy Dashboard移动APP 联系人分组合并报警配额WEB警铃邮件短信私信同比&环比面积图趋势函数节点监控数据API平台业务监控实践●业务日志标准化：profile.log◆监控分类:7大类◆指标项：API 举例C-计数T-时间单位：ms指标total_countslowThresholdslow_countavg-timeival1ival2ival3ival4ival5说明调用量SLA 慢请求平台耗时<500<500-1s><1s-2s><2s-4s>>4s类型CTCTC C C C C资源层APIMC&MCQ MySQL 依赖SERVICEHTTP 依赖Hbase 依赖Redis 依赖API 日志样例：{"type":"API ","name":"/statuses/friends_timeline","slowThreshold":0,"total_count":0,"slow_count":0,"avg_time":"00.00","interval1":0,"interval2":0,"interval3":0,"interval4":0,"interval5":0}业务监控方案●监控选型：Logtailer+Statsd+Graphite●Logtailer封装◆Python实现的agent◆分布式1存储（一致性Hash）◆打包发送（UDP协议）◆本地Cache（10s）●Graphite优化◆高可用部署◆接入Memcached◆Whisper I/O优化（合并写）●监控数据量◆Metrics:Statshd:90k/s Carbon:1800k/s◆指标项：1000+◆报警：<300LogtailerStatsdNginxHAproxycarbon-relaywhispercarbon-cachewhispercarbon-cachewhispercarbon-cachecarbon-relay graphite-webweb app基于Graphite的方案业务监控Dashboard●Graphite Dashboard◆丰富的函数操作及聚合规则◆定制用户自己的Dashboard◆移动端APP◆强大的接口业务模块DashboardAPP端Dashboard APP端报警通知业务监控-完善方案改进版业务监控集群App logJvm loglogstashKibanaElasticSearchStatsDMfiter Graphite资源依赖Http 依赖服务依赖RPC依赖层4/7层Sina WatchSina ScriptsSina Atp用户日志查询报警平台DashboardSpark HbaseWatchManTrace UI部署线日志查询报警平台业务Dashboard Trace单机健康状态监控●集群单机健康状态监控◆指标定义◆实现方案◆数据通道：agent(Python)->SinaWatch ->API ->Dashboard ◆健康状态判断：算法（区间权重+优先级+硬性指标）◆数据展示：异常的节点可获取异常数据分类影响因素好-正常坏-亚健康糟糕-异常系统Load <1212<X<24>24Cpu_idle <30%10%<X<30%<10%Iowait <20%20%<X<35%>50%Swap<500M 1G<X<2G >2G 业务5xx 错误比率<1%1%<x<5%>5%接口平均耗时<100ms100-500ms>1s产品展示图3.主动防御-容量评估●平台容量评估实践◆压力测试方式：集群容量数据一览图 单接口压测：模拟请求（http_load）单机压测：✓线上引流：Tcpcopy(放大/多台引至一台)✓调整Nginx权重：平台自动化化压测系统服务池压测：全链路压测✓机房间流量切换（核心服务）✓Nginx upstream自动变更ps:粒度：1/单IDC Nginx集群数量资源容灾与压测：Touchstone（基于tc）◆容量评估产出：基于Python的自动化压测工具水位预警工具容量报表4.主动防御-干预手段 有效的干预手段是快速解决问题&故障的基石异常处理预案重启/回滚/紧急上线服务降级/封禁流量切换干预手段限流Docker 机动池数据修复快慢定期循检故障演练7x24小时轮班重大事件响应流程&制度操作方案扩容应急预案-服务降级降级Web UI●预案：100+◆日常&应急预案◆重大活动，三节等预案手册●服务降级：5000+◆原则：覆盖全，开关避免手输◆方案：业务代码框架层实现，动态修改运行时环境Tomcat监听端口，支持check/on/off/status集成运维工具系统◆范围：大纲微博平台业务介绍平台防御体系框架设计平台层实践新浪故障管理小结&QA1.新浪故障管理制度●组织形式◆实体故障管理组--跟进故障业务方及运维核心人员--解决故障◆虚拟：TDO-各部门专家支持故障Review，深入挖掘故障本因◆沟通方式：在线：电话，QQ及群，其他IM通知：短信，邮件●管理制度◆拥抱故障◆KPI--故障记分运营KPI与产品良好的用户体验挂钩处理故障能力与KPI挂钩◆奖惩制度：设立运维季度奖，涵盖面广人为故障，责任到人，通告及罚钱2.新浪故障处理流程•接收报障•判断是否为故障•启动故障通报流程•跟进处理进展•判断及启动升级策略•确认解决•发出恢复通报•故障讨论会•发送报告•跟进改进措施故障管理组流程•与报障来源部门确认具体现象确认故障现象故障通知•与TDO协调相关部门处理•每30分钟通报一次进展协调跟进•技术方向升级•故障管理方向升级•客服方向升级级别预判升级•第一时间通知主要工程师及TDO•10分钟内发出短信及邮件•确认故障恢复•5分钟内发出短信•召开故障讨论会故障解决•第一版报告故障4小时后发•故障报告最终版2个工作日内发出故障报告故障管理组主要工作运维&开发故障处理流程数据修复流程•周知相关领导及服务台•初步判断问题并定解决方案•如有上线及变更优先回滚•多方方案并行推进•以停止故障影响为目的•提交数据修复变更申请•主管审批并确定负责人•数据修复方案review•周知各相关方关注服务•实施数据修复3.新浪故障报告●故障定级◆级别：5级，E级为重要问题◆指标：6类，每类细化指标每个产品线指标不同，每类多级重要产品按功能模块划分多级，赋分◆公式：故障级别计算公式●故障原因◆原则：每一个故障及问题追查本因◆分类：研发类和产品线◆分级：一级分类和二级分类一级分类：✧网络类✧局方故障✧应用软件✧硬件设备✧系统类✧人为因素微博故障定级规则A级：85分以上B级：71-84分C级：61-70分D级：41-60分E级：41及分以下（备案不发）权重值衡量指标衡量指标级别30%1、影响微博功能220%2、影响服务时长315%3、影响用户范围415%4、用户投诉级别110%5、影响服务程度210%6、影响用户时段1故障评分64.5故障级别：C级微博故障报告单（要点）故障标题故障描述所属产品线影响功能故障级别影响时长开始时间发现时间恢复时间发现途径故障原因根本原因触发原因影响用户影响用户数计算方法投诉情况责任部门责任人故障分类处理过程改进措施服务影响时长=服务恢复时间-故障开始时间故障定级规则故障故障报告单。
了解一个公司的运营能力，可以单纯从骨骼角度分析。
来看下新浪微博过去几年于运营方面的骨骼结构：从几个并列维度来看，新浪微博主要依靠明星、名人、草根段子帐号、媒体新闻帐号、及微博达人等等产品推动。
但是：明星，在微博世界已然过气。
随着粉丝饱合，他们接触到了天花板然后一路下滑，相信你已经很久没有看到微博女王姚晨的微博转发到你的界面上。
名人：打击大 V 事件给了名人重大打击。
媒体新闻帐号：微博发展了这么些年了，媒体官号运营能力还是良莠不齐，除了抄与雷同之外，难得有新意。
财经类的帐号成千上万个。
关注某一个与关注所有没有太大差别。
微博达人：阿猫阿狗都可以冠以此名。
原来备受诟病的草根段子帐号，却在驱动着相当用户。
可见，驱动新浪微博用户的关键节点，也就是骨骼，出现了严重的问题。
导致依附在上面的用户纷纷流失：在 2009 年开始维持新浪微博大功率运行的骨骼系统，已经不能驱动用户获得新鲜的感觉或者信息。
原来的骨骼老化了。
新浪需要进化——构建新的骨骼系统。
进化原理基于新浪微博特征，可以将骨骼系统想像为重要信息传播节点。
整个新浪微博就是由无数个“重要信息传播节点”构成的。
新浪原来本意上的“重要信息传播节点”是由名人明星官微等构成。
综上所述，原来模式下的新浪微博的“重要信息传播节点”，全部出现问题。
我这里指的“新构架下的重要信息传播节点”，不是仅指粉丝多的大号，而是能为用户提供在“报纸，在腾讯或者搜狐新闻首页，在新浪首页，在报纸杂志上”看不到的信息的微博。
只有他们，能让微博用户看到在别处看不到的信息。
这些微博博主在源源不断的创造着。
就像是新的血液，他们滚动出来的信息让用户感觉到新鲜，增加了用户对新浪微博的粘性，反过来用户的追捧又进一步刺激他们的创造热情。
这是才是一个良好的生态系统。
现形式下微博用户的逻辑是这样的：多数微博用户还是时不时的要回微博看下，这个平台对他们的吸引力还在。
但关键是，他们隔 2 天再登陆微博后，所看到的信息还是平淡的信息流：重复的新闻帐号滚动。
新浪微博分析微博又叫微博客 (micro blog)，是微型博客的简称，基于web2.0技术的即时信息发布系统。
是一个基于用户关系的信息分享、传播以及获取平台，用户可以通过WEB、WAP以及各种客户端组件个人社区，以140字左右的文字更新信息，并实现即时分享。
与传统博客相比，以“短、灵、快”为特点。
140字左右的文字更新信息，并实现即时分享。
微型博客可分为两大市场，一类是定位于个人用户的微型博客，另外一类是定位于企业客户的微型博客。
微博客是信息日益碎片化的必然结果。
“围脖”是微博客的谐音，所以微博也称围脖。
微博客的代表性网站是美国的Twitter，是最早也是最著名的微博，这个词甚至已经成为了微博客的代名词。
新浪作为中国最大的门户网站之一，2009年八月新浪推出新浪微薄测试版，成为门户网站第一家提供微薄服务的网站，微薄正式进入中文上网人群视野！一、新浪微薄发展背景Web2.0时代。
新的媒体形态层出不穷，每一个新媒体形式的出现都意味着Web2.0的普及和网络的进步。
进入2010年，Web2.0更是狂飙突进，中国网民的参与度和活跃呈现爆炸式增长，这一情况的出现，与一种新媒体形态的诞生不无关系—微博。
网络与传统的博客相比，微博发布更便利、传播更迅速，发布字数限制在140字之内，方便用户通过电脑、手机等多平台浏览发布，所发布信息是传达，并可一键转发。
微博相比传统博客那种需要考虑文题、组织语言修辞来叙述的长篇大论，以“短、灵、快”为特点的“微博”几乎不需要很高成本，无论你是用电脑还是手机，只需三言两语，就可记录下自己某刻的心情、某一瞬的感悟，或者某条可供分享和收藏的信息，这样的即时表述显然更加迎合我们快节奏的生活。
微博微博客草根性更强，且广泛分布在桌面、浏览器、移动终端等多个平台上，有多种商业模式并存，或形成多个垂直细分领域的可能。
微博更符合现在人的生活节奏和习惯。
而新技术的运用使得用户更容易对访问者者留言进行回复，从而形成良好的互动关系。
微博(Micro-Blog)顾名思义是微型博客，是一种基于用户关系的信息分享和传播平台,用户可通过浏览器、手机、及时通讯软件(MSN、QQ、Skype等)及外部API接口等多种渠道发布140字以内信息[1]。
支持跨平台交流、与移动设备无缝连接的技术优势,饱含Web2.0特质。
有这么一道题- 微博数据库设计：有A,B,C3个用户，A关注C，C关注A和B；A,B更新后C会收到信息提示,比如：2010-11-16 22：40 用户A 发表a1;2010-11-16 22：41 用户A 发表a2;2010-11-16 22：42 用户A 发表a32010-11-16 23：40 用户B 发表b1;2010-11-16 22：40 用户B 发表b2;问题1：如何设计数据表和查询？问题2：如果C关注了10000个用户，A被10万个人关注，系统又该如何设计？问题1，我的解答是：设计两张表，一张用于表示用户use r，有ID,用户名(userna me)，发布内容（messag e），发布时间(time)等字段；另一张表用于表示用户之间关注，有ID，用户名(userna me)，关注的用户名，开始关注时间等字段。
回去想了想，发现如果数据表照我这样设计的话，问题2的情况就会产生大量的数据，但如果把关注的用户都写在一个记录里那样字符串可能会更大。
所以想听听诸位达人的意见，如果是你们会怎样设计数据表呢？问题1简单而且随意，直接跳过，估计面试的人都不会看。
问题2的困难在于：第一点.C关注的用户太多，设计上必须在显示C的页面的过程中，避免去数据库查询所有被关注的用户是否有更新。
第二点.第二点.A被关注的人太多，设计上必须在A更新的时候，避免去通知所有关注……为避免不必要的复杂连接关系，最好还是设计符合第三范式的关系数据。
微博(Micro-Blog)顾名思义是微型博客，是一种基于用户关系的信息分享和传播平台,用户可通过浏览器、手机、及时通讯软件(MSN、QQ、Skype等)及外部API接口等多种渠道发布140字以内信息[1]。
支持跨平台交流、与移动设备无缝连接的技术优势,饱含Web2.0特质。
有这么一道题- 微博数据库设计：有A,B,C3个用户，A关注C，C关注A和B；A,B更新后C会收到信息提示,比如：2010-11-16 22：40 用户A 发表a1;2010-11-16 22：41 用户A 发表a2;2010-11-16 22：42 用户A 发表a32010-11-16 23：40 用户B 发表b1;2010-11-16 22：40 用户B 发表b2;问题1：如何设计数据表和查询？问题2：如果C关注了10000个用户，A被10万个人关注，系统又该如何设计？问题1，我的解答是：设计两张表，一张用于表示用户user，有ID,用户名(username)，发布内容（message），发布时间(time)等字段；另一张表用于表示用户之间关注，有ID，用户名(username)，关注的用户名，开始关注时间等字段。
回去想了想，发现如果数据表照我这样设计的话，问题2的情况就会产生大量的数据，但如果把关注的用户都写在一个记录里那样字符串可能会更大。
所以想听听诸位达人的意见，如果是你们会怎样设计数据表呢？问题1简单而且随意，直接跳过，估计面试的人都不会看。
问题2的困难在于：第一点.C关注的用户太多，设计上必须在显示C的页面的过程中，避免去数据库查询所有被关注的用户是否有更新。
第二点.第二点.A被关注的人太多，设计上必须在A更新的时候，避免去通知所有关注……为避免不必要的复杂连接关系，最好还是设计符合第三范式的关系数据。
我想至少应该设计三张表，分别是：用户表user：ID，username...；关注关系表attention: ID->ID；发布信息表in fo：ID->message；三张表的设计是比较规范的，至于用户和关注之间的关联要看需求，做join也可以，做DataMap也可以。
个人觉得，需要的逻辑关系在哪儿，而且要进数据库，想不数据量大都不行。
当然关注可以不做在一张表中也是一个选择，按关系类型分开走，可以减少特定需求的查询量。
这玩意得丢内存里头吧memcached 发新的话题的话丢队列里头写数据库去user{befollow[0...n];post[0...n];topics[0..n];}然后，user[befollow[k]].topics=current_user.topics[j];用户只要检查topics就好了要不每次上来来个join什么的，估计数据库就挂了是直接写到数据库的，不能用join,发贴后就丢队列里，向每一个follow我的人的tweet写数据不能用纯粹的关系数据库来解决问题，因为数据量和访问量都很大。
所以设计必须首要考虑性能问题。
我假定前提，1、一个用户不经常更改他的关注对象，2、用户添加关注对象的操作远多于移除关注对象的操作。
3、用户发微博的频率是比较高的，要比更改关注用户操作的频率高。
4、消息的通知到达时间用户是不敏感的有了这些前提，我们做平衡处理。
我们可以忍受1、较慢的删除关注用户操作2、比删除操作快但比发微博操作慢的添加关注用户操作。
3、快的微博提交操作4、慢的消息通知我们每一个用户建立一个InBo x和OutBox，InBo x包含关注我的用户ID，OutBox是我关注的用户ID。
Box分为三个部分，一个是基准Box，一个是添加Bo x，一个是删除Bo x，实际的Box数据是基准Bo x和添加Box的并集和删除Bo x做差集后得到的集合。
1、用户插入关注用户，在用户的OutBox的添加Bo x加入一条，同时在被关注用户的InBo x的添加Bo x也加入一条添加2、用户删除关主用户，在用户的OutBox的删除Bo x加入一条，同时在被关注用户的InBo x的删除Bo x也加入一条添加3、微博产生后发送消息，将发送微博的用户的InBox（其中含基准Box，插入Bo x和删除Box）连同微博操作连接一起发送给消息处理器。
4、消息处理器合并Box，并把Bo x的内容回写到发送微博用户的InBo x的基准Box中。
5、在后台添加一个Bo x合并进程，缓慢的合并用户的Box数据。
6、前台在展示的时候，因为没有合并，展示列表展示OutBox的基准Bo x和我新添加用户的Bo x以及删除用户的Box内容。
前台展示是需要商榷的，看PUM是否接受这种方式，如果不接受，我们只能在刷新时预测查询基准表，并且在页面合并。
因为前台展示通常是分页的，这样会比较难获得准确的分页量，每页的显示量会不同。
如果需要更高的要求，我们只能再添加其他数据结构。
如果需要更快的算法，我们必须抛弃关系数据库，将用户用B+树做索引，对于Box进行另外处理，需要论述的话，能写一个论文了。
更正一下，抛弃关系数据库可能更好的方式是，用用户ID做Hash索引，因为用户不删除，只增加。
同时，我们可以采用的物理架构和产品，我们需要找到一个轻量级的数据库存储引擎，例如我们可以用BDB，操作系统可以用vxWorks，然后专门针对消息发送和Bo x做一套系统。
更正设计，InBox可以不需要，采用客户端拉的机制，可以去掉InBox，带来的问题就是你必须在线才能得到通知。
InBox会很大，需要平衡，像姚晨这样的，会把消息处理器累死，所以，需要筛选，消息处理器的需要另外设计。
消息处理器可以去掉，当用户上线时，查阅关注博主的博文变更记录，根据阅读标志，阅读标志为每个用户建立一组。
进行伪消息通知。
消息处理器存在于需要主动推送的场合。
例如，短信和邮件。
不是所有的用户都会进行短信订阅的，所以消息处理器的负载可以减轻。
陆兄的意思是不是：用DBMS底层的数据库引擎或相关数据结构（比如哈希，B+树等）重新设计一个适合微博应用环境的数据库，而不是利用现有的DBMS进行设计？数据库是需要的，但不应该是关系型的。
自己做数据库是可行的，在这个应用中，或者说需要高速处理的“热”数据中，是不需要关系的，也不应该用关系数据库的设计范式来约束设计。
对于Box这样的数据结构，是不需要保存在一个关系数据库的数据表中的。
做成Hash表会很好，当然可以采用现有的数据库产品，把Box的索引类型定义为Hash的。
很多数据库产品是可以这样处理的。
但是，这样会有麻烦，因为Box和用户紧密关联的，不可能为一个用户去建立一个Hash索引的表，这样你又不得不回到关系数据库的老路上去了。
你可能会说，我可以定义在Hash主键中包含用户的账号，这样Bo x的数据自然会按照用户分开了。
但是，需要获取用户整个Box数据的时候又碰到麻烦，没有和用户关联的索引去快速检索。
能做的就是把Bo x保存在内存或者独立的文件中，在这种应用中对数据完整性的要求是很低的，Box应该在内存中保存，在适当的时机脱水持久化。
而且活跃的Bo x可能很少很少。
所以我的建议是分别处理，持久化一块，“热”的实时播发一块，持久化为了简便采用传统的关系数据库是可以的。
为了性能，需要特别处理。
全部的设计，会很复杂，作为面试题，太难了！为了提高处理能力，并行是不可避免的，需要把Bo x这样的结构分解分发在不同的机器上处理。
但是在这样的应用中，事务又是不需要的，数据完整性也是不需要的，甚至不需要日志来恢复数据，并行处理的时候用传统的RDBMS又会有瓶颈。
所以这不是一个数据库设计问题。
靠做关系数据库的设计是完成不了这样的任务的。
就是一个查询时间换空间的问题本人认为在10万条以内，直接的标准关系型数据库设计就好更大的话可以考虑做空间换时间的设计具体可以做内存空间缓存，文件缓存，数据库缓存都可以就数据库缓存来说，除了标准的关系型数据库外，另外需要加个表做个用户-》关注信息的表每次有被关注的用户发布信息，就把其信息的ID写入被关注用户的用户关注信息表，对这个表可以优化，把比较老的数据及时删除。
还有一种折中的做法就是分别对关注关系的关注用户字段和用户信息的用户字段和时间字段做索引，问题就基本能解决，百万级没有问题如果数量再大，需要对用户信息做时间的分表，保证每个表的信息数量在千万数量级当然，每次访问都读取数据表就是一种愚蠢的做法，短期内数据不更新的情况下应当从内存读取数据或者文件缓存来读取数据缓存的更新又是另外一个话题啦问题2的困难在于：第一点.C关注的用户太多，设计上必须在显示C的页面的过程中，避免去数据库查询所有被关注的用户是否有更新。
第二点.A被关注的人太多，设计上必须在A更新的时候，避免去通知所有关注他的人自己更新了(也就是数据库中为每个人设置标志或者增加记录)。
这两点其实是矛盾的，因为你总需要在某个时候交流“A更新了”这条信息。
就需要在系统设计的时候进行折衷和权衡。
甚至对不同的用户分类采用不同的方案。
可以采用以下的方案：普通用户放到一张表中，视为B类。
假设绝大多数用户都是B类，即关注的人不太多，被关注也不太多。
进一步假设绝大多数的微博记录来自于普通的B类用户。
对那些关注别人太多的，分为C类。
专门为C类用户增加一个表，他关注的人如果不是A类，则每次更新都在这张表里面推送一条记录。
这样显示C的主页时，只用先查询这张表，再在A类人的专属表中查找A类人的更新即可。
因为C类的人数比较少，所以这张表应该会比较小，查找起来会比较快。
对A类的人，则独立出来成为单独的一张表，供别人查询，因为A类的人数较少，所以这张表应该会比较小，查找起来比较快。
这就是一个简单的设计，足以表示你针对问题进行考虑，并给出了有一定效果的解决方案。
当然，这是按照楼上要求的只通过表的设计来实现。
而实际构建系统的时候，该用视图的用视图，该建立索引的建立索引，花样会更多，效果会更好。
以下设计以sqlserver2005为例记录用户信息的用户表Users(uid bigint identity(1000,1) primary key,uname varchar(50) not null unique);记录A对B的关注信息的关注表Attention(byuser bigint foreign key references Users(uid),touser bigint foreign keyreferences Users(uid) primary key(byuser,touser));注：byuser 发起关注者，touser 被关注者记录某人发表文章信息的文章表Article(aid bigint identity(1000,1) primary key,uid bigint foreign key references Users(uid),title varchar(100) not null,context ntext not null,publishDate datetime not null);由于需要获取更新信息，所以要能记录哪些文章是查看过，那些不是的文章状态，并且此状态不是文章的状态，而是每一个文章对于每一个关注者的状态。
