鹿晗新浪微博
如何快速提高系统性能？
回顾一下，究竟是多大的流量使得曾豪言“微博服务器稳定，能同时应付三对劈腿的”壮志秒破功，具体数据如下图所示：
按照微博明星势力榜各个榜单计分方式：满分 100 分，由阅读数、互动数、社会影响力、爱慕值四项组成，所占比例分别为30%、30%、20%、20%。
由上可以看出，鹿晗所发微博的每一项都达到了峰值，那么在如此高流量的情况之下，作为开发者是否有好的方法来快速提高系统性能呢？就鹿晗宣布恋情导致微博宕机事件浅谈大型网站高可用性架构。
作为一名程序员，我更感兴趣的是微博如何应对瞬时涌来的高并发大流量。从很久很久以前文章马伊琍的 “周一见”，到后来 “出轨队”、“吸毒队” 的争相夺分，再到前段时间的郭敬明事件、薛之谦事件，再到今天的鹿晗宣布恋情......
微博看似每次都在挂，一直都没有进步，大家每次遇到热点事件刷不出内容的时候都会吐槽微博的应用平台很辣鸡。但是呢，微博的后台系统肯定一直在重构升级优化，我觉得能够做到今天这种水平已经很不错了。
01
从用户的角度（主要是我的角度 hhhhh）来看
遇到热点事件的时候微博大概率在短时间内（大约 10~15）可能会完全刷不出内容，过了一段时间之后（大约半小时）进行间隔刷新（间隔 10 秒左右），有可能某些时候会看到 5xx 的 ERROR，5 开头的 http 状态码代表服务器或者是网关存在问题。
比如说服务器拒绝连接、网关超时或者是应用代码存在 Bug 等都会导致 5xx 的错误。在热点事件发生 1 小时内，系统应该可以恢复正常的服务。
02
从网站开发、运维人员的角度来看
运维：卧槽？怎么访问流量这么高？是出啥 Bug 了吗？卧槽！不会是又有人出轨吸毒了吧？emmmm.... 我的国庆假期可还没结束啊！
运维：兄弟们，快醒醒！快加机器啊！系统要崩了！
开发：别催！再催自杀！
leader：测试在扩容之后赶紧拉出来测测！
测试：人在家中躺，锅从天上来！
上面都是我乱说的！
为什么我觉得微博在高并发大流量访问方面的表现已经很不错了呢？举个例子吧：淘宝每年在双 11 购物节的时候也要应对高并发的场景，但是这是可以提前做很多准备的。
比如说提前购买带宽资源、增加服务器资源、进行完备的异地容灾等等，很多都是可预测的。而微博呢？热点事件随时都可能发生，所以这对于微博的运维工程师来说是很大的考验。
当然，现在的运维平台也是非常的智能了，可以对各项指标进行实时监控，一有异常，马上进行短信或者邮件报警，之后就是各个岗位的工程师人肉上场调配各类资源了。
那微博在平时为什么不增加一些服务器资源呢？服务器资源、网络带宽资源等既重要，又昂贵。
由于并不是每时每刻都必须应对高并发的场景，因此如果说在平时增加了冗余的服务器资源导致大量机器空载，也是一种很大的浪费。我们在考虑提供可用服务的同时，也必须考虑一下成本。下面我就针对高可用性架构中经常会提到的几个点来讲讲。
大型网站高可用架构
不管是对于小型网站还是大型网站来说，分层都是必须的：粗粒度的分层一般为应用层、业务层和数据层。横向分层之后，可能还会根据模块的不同对每一层进行纵向的分割。
拿微博举例，我觉得它的评论模块和点赞模块应该是解耦的。越是复杂的系统，横向和纵向的分层分割粒度就会越细。很多时候你用起来以为它就是一个系统，其实后面可能是由几百上千个独立部署的系统对外提供服务。
集群
集群在大型网站架构中是一个非常非常重要的概念。由于服务器（不管是应用服务器还是数据服务器）容易发生单点问题，一旦一台服务器挂了，就必须进行失效转移。
应用服务器集群
一般来说，应用服务器必须是无状态的。什么叫无状态服务器呢？在介绍它之前，我们先来说一下状态服务器：状态服务器一般会保存请求相关的信息，每个请求会默认地使用以前的请求信息。
这样就很容易导致会话粘滞问题：如果一台状态服务器宕机了，那么它保存的请求信息 (例如 session) 就丢失了，可能会导致不可预知的问题。
那么相对的，无状态服务器就不保存请求信息，它处理的客户信息必须由请求自己携带，或者是从其他服务器集群获取。
因此无状态服务器相对于状态服务器来说更加地健壮，就算是重启服务器甚至是服务器宕机都不会丢失状态。由此引申出来的另一个优点就是方便扩容：只要在增加的服务器上部署相同的应用并做好反向代理就能对外提供正常的服务。
Session 管理
既然应用服务器是无状态的，那么用户的登录信息 (session) 如何管理呢？比较常见的有下面四种方式：
session 复制
源地址 hash（session 绑定）
用 cookie 记录 session
session 服务器
但是由于前三种都有很大的局限性，这里只聊聊基于集群的 session 服务器管理方式。
我们在这里是将服务器的状态进行分离：分为无状态的应用服务器和有状态的 session 服务器。
当然，这里说的 session 服务器肯定说的是 session 服务器集群。我们可以借助分布式缓存或者是关系型数据库来存储 session。
对于微博来说，这里肯定得用分布式缓存了：因为用关系型数据库的话，数据库连接资源容易成为瓶颈，并且 I/O 操作也很耗时间。
比较常见的 K-V 内存数据库有 Redis。我觉得微博内容中的赞数、用户的关注数和粉丝数用 Redis 来存应该算是比较合适的。
既然提到了集群，肯定得说说负载均衡。但是感觉负载均衡应该可以归类到可伸缩性里面去，所以这里就不详细讲啦，就简单说说有哪些常见的负载均衡的方式以及负载均衡算法。
负载均衡方式：
HTTP 重定向负载均衡。
DNS 域名解析负载均衡。
反向代理负载均衡。
IP 负载均衡。
数据链路层负载均衡。
负载均衡算法：
轮询法。
随机法。
源地址哈希。
加权轮询。
加权随机。
最小连接数。
插播点别的
突然想到一个比较有意思的东西：在微博的架构中，应该采用的是异步拉模型而不是同步推模型。
什么意思呢？我们举个例子：鹿晗的粉丝有 3000 多万，关晓彤的粉丝有 1000 多万。假如他俩发了条微博的同时需要往这 4000 万粉丝的内容列表中 (假设这里用的是关系型数据库) 推送过去，这就是简化的同步推模型。
那这样有什么缺点呢？首先，这样会消耗大量的数据库连接资源，更重要的是这样不太符合软件设计规范：因为对于两人的粉丝来说，分别由有 3000 多万和 1000 多万的数据是冗余的。
假如说陈赫、邓超在第一时间对他俩的微博进行了点赞，此时瓶颈就来了：刚才往数据库里插入 4000 多万感觉还可以接受，但是现在四人的粉丝数加起来好几亿了，同时往数据库插这么多数据是不是感觉不太合适？
没关系，我们现在换一种内容推送方式：我们现在不用同步推了，而是用异步拉。我们每次在手机上刷微博的时候，如果想要看到更新的内容是不是都要下拉刷新获取？没错这就是异步拉。
异步拉有什么好处呢？很明显的一个好处就是可以将热点数据进行集中管理，并且不用进行大量的数据插入冗余操作。另外对系统资源的消耗也较少。
那么微博内容从哪里拉呢？主流的解决方案是把热点内容放到缓存中，每次都去查缓存，这样可以减少 I/O 操作并且避免发生因资源枯竭造成的超时问题。
其实高可用性架构还包括服务升级、服务降级、数据备份、失效转移等等。关于网站高可用、高性能、高拓展方面感觉还有很多很多东西来写。但是有些知识没有一定的实践经验呢，又不能很好的掌握。
相关阅读
第一步，注册一个有趣味的微博名字，如减肥瘦身百科，护肤美妆百科，美食营养百科。这样做的目的是便于搜索，目前也是女生关注最多的话题。
1、进入新浪微博开放平台http://open.weibo.com/index.php使用账户登录2、点击【网站接入】或者在最上方菜单【微连接】中选择,进
一篇好的软文往往能直击用户痛点， 使用户产生共鸣，快速提升消费者对品牌的好感。那么如何写好一篇高质量品牌软文，软文营销又有哪些
@keso 新浪是媒体，新浪微博也是媒体，不是说媒体公司就一定做不成社交，而是希望在微博这棵树上长出社交的枝干，再反过来把微博的媒体
化繁为简，是科技发展的核心目的之一，在零售行业，消费和运营流程的简化、人员结构的优化，在一次次的技术变革中获得不断的突破。近几年