企业官网建设流程全解析

网站建设合同附件格式,浩森宇特北京网站建设,.net 企业网站源码下载,织梦企业网站源码技术开发者往往对微博这个产品非常关心#xff0c;对微博的构架非常感兴趣#xff0c;就是一个明星他有300万粉丝#xff0c;这个技术怎么来实现#xff1f;今天在这里跟大家分享一下微博的底层机构#xff0c;让大家对微博的底层技术有更好的了解。另外不管是做客户端、W…技术开发者往往对微博这个产品非常关心对微博的构架非常感兴趣就是一个明星他有300万粉丝这个技术怎么来实现今天在这里跟大家分享一下微博的底层机构让大家对微博的底层技术有更好的了解。另外不管是做客户端、Web1.0、Web 2.0、论坛、博客都要考虑架构的问题架构实际上是有一些共性的。今天我通过讲解微博里面的一些架构分析一下架构里面哪些共性大家可以参考。首先给大家介绍一下微博架构发展的历程。新浪微博在短短一年时间内从零发展到五千万用户我们的基层架构也发展了3个大的版本。第一版就 LAMP架构优点是可以非常快的实现我们的系统。我们看一下技术特点微博这个产品从架构上来分析它需要解决的是发表和订阅的问题。我们第一版采用的是推消息模式假如说我们一个明星用户他有10万个粉丝那就是说用户发表一条微博的时候我们把这个微博消息存成10万份这样就是很简单了第一版的架构实际上就是这两行字。第一版的技术细节典型的LAMP架构是使用MyISAM搜索引擎它的优点就是速度非常快。另外一个是MPSS就是多个端口可以布置在同一服务器上。为什么使用MPSS假如说我们做一个互联网应用这个应用里面有三个单元我们可以由2种部署方式。我们可以把三个单元分别部署在三台服务器上另外一种部署模式就是这三个单元部署在每个服务器上都有。我推荐第2种方法。这个方法解决了两个问题一个是负载均衡因为每一个单元都有多个节点处理另外一个是可以防止单点故障。如果我们按照模式1来做的话任何一个节点有故障就会影响我们系统服务如果模式二的话任何一个结点发生故障我们的整体都不会受到影响的。我 们微博第一版上线之后用户非常喜欢这个产品用户数增长非常迅速。我们技术上碰到几个问题。第一个问题是发表会出现延迟现象尤其是明星用户他的粉丝多 系统需要处理很长时间。另外系统在处理明星用户发表时系统繁忙可能会影响到其他的用户因为其他的用户同一时间发表的话也会受到这个系统的影响。我们就 考虑这个系统怎么改进。首先是推消息模式这肯定是延迟的首要原因我们要把这个问题解决掉。其次我们的用户越来越多这个数据库表从一百万到一亿 数据规模不一样处理方式是有差别的。我们第一版单库单表的模式当用户数量增多的时候它不能满足就需要进行拆分。第二个是锁表的问题我们考虑的是更改 引擎。另外一个是发表过慢我们考虑的是异步模式。第 二版我们进行了模块化我们首先做了一个分层最底层叫基础层首先对数据做了拆分图上最右边是发表做了异步模式。第二个服务层我们把微博基础的单元 设计成服务层一个一个模块最大改进是对推模式进行了改进。首先看一下投递模式的优化首先我们要思考推模式如果我们做一下改进把用户分成有效和无效的 用户。我们一个用户比如说有一百个粉丝我发一条微博的时候不需要推给一百个粉丝因为可能有50个粉丝不会马上来看这样同步推送给他们相当于做无用功。我们把用户分成有效和无效之后我们把他们做一下区分比如说当天登陆过的人我们分成有效用户的话只需要发送给当天登陆过的粉丝这样压力马上就减轻了另外投递的延迟也减小了。我们再看数据的拆分数据拆分有很多方式很多互联网产品最常用的方法比如说如可以按照用户的UID来拆分。但是微博用户的一个特点就是说大家访问的都是最近的数据所以我们考虑微博的数据我们按照时间拆分比如说一个月放一张表这样就解决了我们不同时间的维度可以有不同的拆分方式。第二个考虑就是要把内容和索引分开存放。假如说一条微博发表的uid微博id是索引数据140个字的内容是内容数据。假如我们分开的话内容就简单的变成了一种key-value的方式key-value是 最容易扩展的一种数据。索引数据的拆分具有挑战比如说一个用户发表了一千条微博这一千条微博我们接口前端要分页访问比如说用户需要访问第五页那我 们需要迅速定位到这个记录。假如说我们把这个索引拆分成一个月一张表我们记录上很难判断第五页在哪张表里我们需要加载所有的索引表。如果这个地方不能 拆分那我们系统上就会有一个非常大的瓶颈。最后我们想了一个方法就是索引上做了一个二次索引把每个月记录的偏移记下来就是一个月这个用户发表了多 少条ID是哪里就是按照这些数据迅速把记录找出来。异 步处理发表是一个非常繁重的操作它要入库、统计索引、进入后台如果我们要把所有的索引都做完用户需要前端等待很长的时间如果有一个环节失败的话 用户得到的提示是发表失败但是入库已经成功这样会带来数据不一致问题。所以我们做了一个异步操作就是发表成功我们就提示成功然后在后台慢慢的消息 队列慢慢的做完。另外新浪发表了一个很重要的产品叫做MemcacheQ我们去年做了一个对大规模部署非常有利的指令就是statsqueue适合大规模运维。第二版我们做了这些改进之后微博的用户和访问量并没有停止还有很多新的问题出现。比如说系统问题单点故障导致的雪崩第二个是访问速度问题因为国内网络环境复杂会有用户反映说在不同地区访问图片、js这些速度会有问题。另外一个是数据压力以及峰值MySql复制延迟、慢查询另外就是热门事件比如说世界杯可能会导致用户每秒发表的内容达到几千条。我们考虑如何改进首先系统方面允许任意模块失败。另外静态内容第一步我们用 CDN 来加速另外数据的压力以及峰值我们需要将数据、功能、部署尽可能的拆分然后提前进行容量规划。另一方面我们还有平台化的需求去年11月我们就说要做开放平台开放平台的需求是有差异的Web系统它有用户行为才有请求但是API系统特别是客户端的应用只要用户一开机就会有请求直到他关闭电脑这种请求一直会不间断的过来另外用户行为很难预测。系统规模在持续的增大另外也有平台化的需求我们新架构应该怎么做才能满足这些需要我们看一下同行比如说Google怎么样考虑这个问题的Google首席科学家讲过一句话就是一个大的复杂的系统应该要分解成很多小的服务。比如说我们在Google.com执行一个搜索查询的话实际上这个操作会调动内部一百多个服务。因此我们第三版的考虑就是先有服务才有接口最后才有应用我们才能把这个系统做大。现在我们看一下第三版首先我们把底层的东西分成基础服务基础服务里面有分布式的存储我们做了一些去中心化、自动化的操作。在基础服务之上有平台服务我们把微博常用的应用做成各种小的服务。然后我们还有应用服务这个是专门考虑平台各种应用的需求。最上面我们有APIAPI就 是新浪微博各种第三方应用都在上面跑。平台服务和应用服务是分开的这样实现了模块隔离即使应用服务访问量过大的话平台服务不会首先影响。另外我们把 微博的引擎进行了改进实现了一个分层关系。用户的关注关系我们改成一个多惟度的索引结构性能极大的提高。第四个层面就是计数器的改进新版我们改成 了基于偏移的思路就是一个用户他原来读的一个ID比如说是10000系统最新的ID是10002的话我们很清楚他有两条未读。原来的版本是采用绝对计数的这个用户有几条未读都是用一个存储结构的话就容易产生一致性的问题采用这种偏移的技术基本上不会出错。另外基础服务DB冷热分离多维度拆分在微博里面我们是按照时间拆分的但是一个大型的系统里面有很多业务需要有不同的考虑。比如说私信这个就不能按照时间来拆分这个按照UID来拆分可能更简单。然后我们突出存储还做了一个去中心化就是用户上传图片的速度会极大的提高另外察看其他用户的图片速度也会极大的提高。另外是动态内容支持多IDC同时更新这个是在国内比较新颖的。下面给大家介绍一下新浪微博怎么样打造一个高性能架构。到目前为止有五千万用户使用新浪微博最高发表3000条以上每秒然后一个明星用户发表的话会被几百万用户同时读到。这些问题的本质是我们架构需要考虑高访问量、海量数据的情况下三个问题。易于扩展、低延迟、高可用和异地分布。我们每天有数十亿次外部网页以及API接口的需求我们知道微博的特点是用户请求是无法cache的。因此面对这个需求我们怎么样扩展几点思路。第一我们的模块设计上要去状态我们任意一个单元可以支持任意节点。另外是去中心化避免单点及瓶颈。另外是可线性扩展。最后一个是减少模块。我们要做一个高性能的系统要具备一个低延迟、高实时性微博要做到高实时性这是核心的价值实时性的核心就是让数据离CPU最近避免磁盘的IO。我们看淘宝核心系统专家余锋说过的一句话“CPU访问L1就像从书桌拿一本书L2是从书架拿一本书L3是从客厅桌子上拿一本书访问主存就像骑车去社区图书馆拿一书”。我们微博如果要做到非常实时的话我们就需要把数据尽量离CPU节点最近。所以我们看一下cache设计里面怎么达到这个目标。首先INBOX这个数据我们需要放再一个最快的地方因为用户随时访问。OutBOX里面的最近发表就是L1cache还有一个是中期的这个因为访问少一点它可以被踢。最后一部分内容体有三部分。L0是本地的我们需要把一些经常访问的比如说明星发表微博的内容体本地化因为它被访问的概率非常大。然后L1里面存放着最近发表的还有一个是中期的。我们通常用L2就可以了L1我们可以理解成它就是一个RAM存储。一个好的架构还需要举行高可用性。我们看一下业界的指标S3是99.9%EC2是99.5%我们另外一个同行Facebook在这方面它是没有承诺的就是接口可用写。微博平台目前承诺的是99.95%就是说一天365天故障率应该小于9小时。这个怎么达到第一我们要做容量规划要做好监控以及入口的管理就是说有些服务如果访问量过了的话我们要有一个开关可以拦住他。我们通过这个图表可以清楚的看到比如说我们要做L1的 cache我们剩余空间有多少比如说80%就说明这个数据有可能会丢失有可能会对我们的系统造成影响。另外一个层面就是接口监控我们目前有Google维度的接口监控包括访问错误失败率。然后要做架构给大家一个很重要的经验分享就是说监控的指标尽量量化。比如说他延迟30秒是小问题如果是延迟10分钟我们就要立即采取措施了就是所有可以量化的指标都要量化。然后我们看监控怎么样更好的做我们看亚马逊的VP说过的一句话就是说监控系统确实特别好可以立即告诉我们哪里有故障但是有20%的概率我们人是会出错的。所以我们一个大型系统就应该要为自动化设计就是说尽可能的将一些运作自动化。比如说发布安装、服务、启用、停止。我们再看另外一句Google的 工程师是怎么做的。他是这么做的比如说第一周是处理线上的业务这一周他处理了很多事情处理了很多系统的情况剩下几周时间没有别的工作他只要把这 一周碰到的情况用程序的方法来解决下次再碰到这种情况很简单的一个按钮就可以处理了。我们目前也在向自动化这方面努力就是我们的工具在持续增加。另外一个异地分布在国内网络环境下比如说IDC灾难机房检修甚至是机房掉电我们也碰到过中国最好的机房也会掉电所以要每个服务单元都能支持多机房部署。另外做多机房部署有一个好处就是用户的访问速度会提高。多IDC分布静态内容就不说了基本上大的互联网公司都会做它非常成熟基本上没有什么问题比如说图片等等的静态内容。动态内容的CDN分 布是业内的难点国内很少有公司能够做到非常成熟的多机房动态内容发布的成熟方案它的核心就是分布式存储。一款理想的分布式存储产品它有哪些需求呢首 先它要支持海量规模、可扩展、高性能、低延迟、高可用。第二个是需要多机房分布能够满足国内负责的网络环境还要具备异地容灾能力。第三个就是要调用简 单具备丰富数据库特性。因此分布式存储需要解决一个多对多的数据复制。如果要做复制无非是三种策略第一个是Master/Slave但是它也两个缺点第一个是Master是中心化的如果Master在北京那广州访问就非常慢。第二个缺点是有单点风险的比如说Master在北京能立即迁到广州吗这样有个时间窗口的数据就丢失了而且需要人工的干预而且日常广州的用户访问北京的Master是有很大延迟问题的所以一般来说要做的非常优秀是不会考虑第一种方案的。第二种就是Multi-Master 方案它需要应用避免冲突就是我们不能多处改变。这个对于微博来说不会特别难我们的用户通常只会再一个地方发表微博用户不会同时在广州又在北京发表或者是修改自己的资料这样的话我们应用上就已经避免了这种情况。第三个就是Paxos就是可以达到强一致写就是一条数据如果成功肯定是多个机房都成功了这个也显而易见就是延迟性非常大。因此总结一下Multi-Master是最成熟的策略但是它现在没有成熟的产品因为确实没有。我 们再来看微博的方案所以我们自己实现了一个多机房同步的方案。就是我们前端应用将数据写到数据库再通过一个消息代理相当于通过我们自己开发的一个技 术将数据广播到多个机房。这个不但可以做到两个机房而且可以做到三个、四个。具体的方式就是通过消息广播方式将数据多点分布就是说我们的数据提交给 一个代理这个代理帮我们把这些数据同步到多个机房那我们应用不需要关心这个数据是怎么样同步过去的。用这种消息代理方式有什么好处呢可以看一下Yahoo是怎么来做的第一个是数据提供之后没有写到db之后是不会消失的我只要把数据提交成功就可以了不需要关心数据怎么到达机房。第二个特点YMB是一款消息代理的产品但是它唯一神奇的地方是为广域网设计的它可以把多机房应用归到内部我们应用不需要关注这个问题。这个原理跟我们目前自己开发的技术相似。然后我们再看一下目前即将推出的微博平台的新架构。我们知道API大部分的请求都为了获取最新的数据。API请求有一个特点它大目前调用都是空返回的比如说一款手机的客户端每隔一分钟它都要调用服务器一下就是有没有新数据大目前的调用都是空返回就是说不管服务器有没有数据都要调用一次。这次询问到下一次询问中间如果有新的数据来了你是不会马上知道的。因此我们想API能不能改用推的方式就是客户端不需要持续的调用如果有新数据就会推过去。技术特点显而易见低延迟就是从发表到接受1秒内完成实际上可能用不了1秒。然后服务端的连接就是高并发长连接服务就是多点都连接在我们的服务器上这个比传统的API要大很多。我们看一下推送架构怎么从架构底层做到实时性的。从左上角的一条微博在我们系统发布之后我们把它放在一个消息队列里面然后会有一个消息队列的处理程序把它拿过来处理以后放到db里面。假如说我们不做持久化因为我们推送数据也不能丢失我们就要写一个很复杂的程序将数据异步去存这样就会非常复杂而且系统也会有不稳定的因素。从另外一个角度来说我们做持久化也是做过测试的。我们推送整个流程可以做到100毫秒和200毫秒之间就是说我们在这个时间能把数据推送出去。我们再看一下内部细节就是我们收到数据之后首先要经过最上面RECEIVER。 然后推到我们的引擎里面这个引擎会做两个事情首先会把用户的关系拿过来然后按照用户关系马上推送给他相应的粉丝。所以我们调用方已经在那儿等待了 我们需要有一个唤醒操作就是说在接口这儿把它唤醒然后把它发送过去。最后是一个高并发的长连服务器就是一台服务器支持10万以上的并发连接。最右边中间有一个圆圈叫做Stream Buffer我们需要Stream Buffer是要保存用户最近的数据。因为用户可能会有断线的比如说他发送数据的时候断线半分钟我们需要把这半分钟补给他。这就是我们的推送架构。下 面介绍一下平台安全部分。由于我们的接口是完全开放的所以我们要防范很多恶意行为有很多人担心我们接口是开放的是不是有人通过这个接口发垃圾广告 或者是刷粉丝我们技术架构怎么来防范这一点呢这是我们的安全架构做了三个层面的事情。最上面是我们有一个实时处理比如说根据频度、内容的相似性来 进行判断判断发的是不是广告或者是垃圾内容。中间这个是一个日志处理器我们会根据一些行为进行判断比如说如果我们只是实时拦截的话有些行为很难防 止我们做了个离线纠正的模块比如说他潜伏的几个月开始发广告了我们可以事后把这些人清除掉以保证我们平台的健康。最后是通过监控的维度来保证内容 的安全。目前内容安全的架构大概是541的体系就是说我们的实时拦截可以做到50%的防止离线分析大概可以做到40%的防止。微博平台需要为用户提供安全及良好的体验应用以及为开发者营造一个公平的环境所以我们的接口需要清晰安全的规则。从一个APP调用我们的接口需要几个阶层需要划分不同的业务模块。第二个是安全层。第三个是权限层。这是我们平台安全的两个维度一个接口安全一个是内容安全。我 今天讲的是架构方面的问题在座大部分是开发者可能大家都在处理不同的架构问题架构很多地方是相通的。我们需要做一个软件系统需要解决的本质问题是什 么微博第一版解决发布规模问题第二版是解决数据规模的问题第三版是解决服务化的问题。将复杂的问题简单化之后我们才可以设计出一个容易扩展的大规 模架构。我今天介绍就这么多我们微博实际上是很需要各方面的技术人员大家对我们的架构如果感兴趣的话、对我们的系统感兴趣的话也希望各方面的技术人 员参与我们微博的团队随时可以给我微博上发私信。杨为华今天主要给大家介绍一下微薄cache设计在我们业界有一个趋势就是平台和应用。以前Web1.0发展到Web2.0有一种更进一步趋势就是转变成平台和应用。很多应用不是单纯一个Web应用国内已经有不少公司做这个方向做Web2.0或者cache刚开始都是自己模式希望能够把这个行业一些人聚合起来大家一起交流大家犯过的一些错误可以避免让我们做事情更有效率。最早我们新浪曾经有一个DB产品刚开始做通过我们社区介绍慢慢让大家知道DB在一些方面用起来更适合大家的地方后来比如说我们去年发展一种分布式的现在随着社区大家互相介绍如果有人单独讲一个DB会 觉得很不好意思。微博最早我们只能看国外的慢慢有不少公司做这个刚开始我们介绍一些基本技术比如说微博的东西可以用推和拉做等到以后经过我们把这 个话题讲到以后有人再讲微博技术光讲推和拉觉得不好意思要进行一些更深入的话题慢慢我们就在这个过程当中。今天讲一下cache的设计我讲过一次微薄扩展设计那是一个基本话题刚才也讲了一个架构讲得比上次更深刻光讲一个推是不够的我今天演讲主要从是cache进一步补充一下一部分是Feed架构简介第二是cache的设计。微博技术核心主要三个一条微博有很多关注的人分别将你发表的微博分发到你所有关注的人聚合就是打开微博首页这里看到我关注人的信息以及这个微博信息的展现微博在技术上也称之为status或者Feed下面图就是一个典型的Feed。Feed架构刚才是两种设计模式推或者拉还有第三种方式叫做复合型。做到一定程度单纯推或者拉是不够的。推的话如果把Feed比喻成邮件推就是inbo不惜是收到的微博OUTPOX是已发表的微博发表到所有的粉丝查看就是直接访问到。PUSH优点就是实现简单通常做一个种型是首选方案缺点就是分发量。PULL发表是在自己的outbox查看是所有关注对象的inbox。 优点节约存储缺点是计算大量峰值问题。当前访问量比较大是不是计算得过来服务器是不是够用假如说你的服务器是按照你峰值规划你的服务器在平时时 候是非常多的空闲这个是不合理不管推和拉都有一些共同的难题比如说峰值的挑战比如说世界杯活动在新浪微博每秒钟发表量达到2500条我们可以使用异步处理2500个峰值处理速度慢一点你关注人不能马上看到峰值过后保证系统不会被峰值压跨下面就是cache现在有一句话对于这种real—time就是说传统硬盘已经不够用很多东西要分放在硬盘里面才能满足需求。因此cache设计决定了一个微博系统的优劣。里面是一种复合型不是一个简单的推或者拉的类型因为就是说像我们新浪微博到这个级别要做很多优化从模型上就是一个推或者拉的模型我们按照它的关系来说把cache分成需要四种存储的东西这两个里面跟索引比较类似第三就是列表和客户自己资料。看一下第一部分就是inbox微博首页开始ID列表完全是内存里面但是有一个缺点我们要添加元素需要先AET再SET第二部分outbox发出微博有存储最新ID在于聚合。为了高效我们通常分两部分第一就是说最新的一个ID列表比如说我们有100条内容这个用户很久没有来这个是空要过来取就要从我工作列表用ID地址聚合起来第三部分是关注列表这些都是纯ID然后followingfollowing加载开销比较大上百万粉丝越大的集合越容易变更改变则需要deleteall减少使用followinglist场景第四部分contetcache微博内容体里面有一个很重要的内容热内容。这个用户有200万粉丝这个内容是热内容在线粉丝也非常多多分防止单点访问瓶颈最终格式预生成apenAPI需要返回xmljson格式。刚才说了介绍cache的架构现在介绍cache的第二个方面就是使用流程。有一个典型的场景比如说发表我们cache怎么操作首页展现怎么操作。发表需要改变三个内容首先我们要声称contentcache对于常规contentcache我们也要做复制如果对方粉丝在线会在inbox数值ID变更。第三方面修改outbox根据粉丝列表修改inbox数据列表然后首页Feed操作流程。左边有两个inboxoutbox。两个是可选的如果inbox没有我们有一个树型计算我们会根据ID列表聚合起来反馈给I用户。获取首页Feed的流程首先间看inbocache是否可用获取关注列表聚合内容从following关系根据idlist返回最终Feed聚合内容。最常用两个流程就是这样。下面介绍微博cache经验谈首先说流量。打开首页这个时候打一个I来说比如说contentcache为例比如multigntn条Feedcache大小等于N并发清且如1000次/秒总流量等于5020K。假如我们机房里面有1万并发需要800MBPS贷款如果不改变价格这个流量是实现不了。再一个1G内网我们做了很多压力测试一般环境跑三四百兆已经不错了你网内不光是访问cache开销还有很多其他流量因此我们需要优化带宽访问我们可以把热门数据加载到localcache要用压缩算法可以做复制有的时候将一个内部cache分组不同的服务器组访问不同的cache减少内网通信的开销。第一个问题就是带宽的问题其中内销cache开销访问量大第一会碰到瓶颈。第二问题就是hotKeys我们要访问姚晨的微博我们要建设一个Ilocolcache删除时间要把所有的都删除。cache规划方面一些问题将不同业务不同长度KEY存储到不同的MEMcache不同的业务有不同的生命周期LRUcache小量memorystorage大部分更高效的内存利用。mutex什么情况会出现这个问题比如说一个很热的内容cache里面没有了因为memcache不是很可靠的东西你放在里面可能会消失经常出现这样的情况一个很热的cache没有了因为我们系统有很多并发很热数据没有了非常多的并发如果我们没有一个很好的策略比如说几十个几百个加一个内容这会是一个悲剧。我们给每个KEY加载MUTEX这个并发连接取数据库然后把mutex删除成规这个时候我只需要一个连接数据库加载到BD里面有可以了。因为前面已经介绍很多内容我今天介绍一个很简单的东西就是想关注更多微博平台的技术有三个方向一个就是S2技 术沙龙每个月举行一次另外就是说对很多讲师光做讲座不过瘾讲座只是传授别人东西没有能够交流所以我们对一线架构师有一个自己线下交流我们讨论 一些实际中遇到的问题对这些架构师有帮助提高交流一下自己正在做或者有一些东西还不成熟不适合拿出来讲的东西可以线下交流。另外我们有各新浪微 博开发大会会介绍更多微博平台架构分享的东西。S2技术沙龙介绍了希望关注分享Web2.0技术下面有一个它的网址另外就是说介绍一下即将举行一个新浪微博开发者大会主要除了宣传作用希望更多分享新浪微博技术比如说这个平台需要架构与存储可能到时候讲比今天更深入一些会讲一些sinaappengine技术数据挖掘合作与商业模式开发者与平台。目前有一个开发平台的网站。今天介绍比较简单主要是这样看看有什么可以提问。提问我想问一下新浪微博设计之初有没有考虑过安全的问题图片存储等等这种方面的问题这个微博设计之初考虑很多安全方面工作我想了解一下这方面有什么看法和见解。杨 为华我们也在解决两个方面一个用低质量内容有一些搜索用户可能做了一些不好的东西故意出现一些关键字让自己搜索排名更靠前有一些用户发广告对 于传统广告我们有一些技术新浪博客有一些技术通过一些词语热度可以判断一些内容是不是广告内容。实时搜索我们也正在做这方面我们也刚开始起步。提问我之前是跟腾讯微博有相关的但是我已经不在腾讯了。杨为华没关系腾讯微博也可以一起探讨。提问我想问一个比较细节的问题你说到为了节省内部带宽的问题会使用到logcache这个部署你们是跟Web2.0服务器放在一起还是什么杨为华每个前端布置一个cache另外还有一些APC那种基础非cache的技术或者其他内存数据共享这种非标准的方式都可以做cache是一个很泛的观念。提问获取cache会用MUTEX的技术。这个环节具体是什么这个环节是在哪个环节做的杨为华写到一个典型的场景热点内容有很多人同时访问这个网站这个cache量没有了如果不做任何保护实际上数据库访问压力很大还有其他场景还没有复制过来数据就过来了很多人认为cache没有加载访问数据库也是比较悲剧。提问这些东西是在应用这个层次做还是类似也有一个cache上面做杨为华我们是应用做的。提问我请问一下您微博系统使用cacheDV。杨为华计数方面用了。提 问你有一个推模式你用复合模式你们简单介绍一下你们怎么用这个复合模式对微博每个人都会有一些好友有会跟随一些人能不能讲一下对于个人主界面缩 影算法我看到我的界面怎么知道哪些人在前面哪些人在后面能说一下你们的算法每个人登陆进去有一个我的主界面我有一些好友也是一些人的粉丝你 们怎么做排序杨为华我们就是时间排序最简单的方法我们没有找到更好的算法之前。提问不是根据一些热点杨 为华我们也考虑过那个方向但是我们认为挑战性非常大你认为好的方法用户不一定认可这个挑战很大。你用算法做一些东西但是用户认为不重要的东西 如果用户没有展示用户可能也会有其他看法。为什么用复合模式我们也不知道为什么叫复合模式我们根据实时运行情况发现哪里有瓶颈我们会想到更好的方 法解决。这个瓶颈能不能给在线用户加一个什么东西减少系统压力不影响原来的价值主要处于每个性能模块的角度考虑的。提问你能不能说一下一个用户登陆以后你们做了一些什么步骤我估计有些是用推的有些是用拉各个平台设计微博不一样有的速度很快有的会有延迟你能介绍你们用户交流流程吗杨为华这个图可以看到最前面还有别的cache用刚才方式我们看有没有命中如果没有通过OTUBOX关注列表进行计算然后把结果合并起来在上面有一些配件成了cache反映给用户整个流程跟这个图上原理来说区别不大。https://www.cnblogs.com/aspnethot/articles/2447266.html