jysf98746的博客

系统负载（System Load）是系统CPU繁忙程度的度量，即有多少进程在等待被CPU调度（进程等待队列的长度）。平均负载（Load Average）是一段时间内系统的平均负载，这个一段时间一般取1分钟、5分钟、15分钟。[Load1，单核][Load2，双核]希望上面的图对大家理解Load Average有帮助，赶快uptime一下，看一下自己系统的负载吧。

（2）假设共N个线程，其中只有1个leading线程（等待任务），x个processing线程（处理），余下有N-1-x个following线程（空闲）此观点不对，一个消息队列，其仍是临界资源，仍需要一把锁来保证互斥，只是锁竞争从leading移到了消息队列上，此时消息队列仅仅只能起到消息缓冲的作用。（4）事件/任务来到时，leading线程会对其进行处理，从而转化为processing状态，处理完成之后，又转变为following。（6）following不干事，就是抢锁，力图成为leading。

Chubby系统提供粗粒度的分布式锁服务，Chubby的使用者不需要关注复杂的同步协议，而是通过已经封装好的客户端直接调用Chubby的锁服务，就可以保证数据操作的一致性。Chubby具有广泛的应用场景，例如：（1）GFS选主服务器；（2）BigTable中的表锁；

分布式环境下，多台机器上多个进程对一个数据进行操作，如果不做互斥，就有可能出现“余额扣成负数”，或者“商品超卖”的情况，如何实现简易分布式锁，对分布式环境下的临界资源做互斥，是今天将要讨论的话题。原理：多个访问方对同一个资源进行操作，需要进行互斥，通常是利用一个这些访问方同时能够访问到的lock来实施互斥的。（2）只有一个进程会抢到这个锁，即只有一个进程对缓存set key=123能够成功，不成功的进程下次再来抢。（1）多台机器上多个进程对这个锁进行争抢，例如在缓存上同时进行set key=123操作。

通常有两种方案，一种是自顶向下的迁移，一种是自底向上的迁移，这两种方案在58到家和58同城分别实行过，都是可行的，方案有类似的地方，也有很多细节不一样，因为时间关系展开说一种，在58到家实施过的“自顶向下”的机房迁移方案，整个过程是平滑的，逐步迁移的，可回滚的，对业务无影响的。充分的测试完一个业务的站点层和服务层之后，为了求稳，先切1%的流量到新机房，观察新机房的站点与服务有没有异常，没有问题的话，再5%，10%，20%，50%，100%的逐步放量，直至第一波蚂蚁搬完家。多机房架构是什么样的架构呢？

普及：DAT是double array trie的缩写，是trie树的一个变体优化数据结构，它在保证trie树检索效率的前提下，能大大减少内存的使用，经常用来解决检索，信息过滤等问题。查询的步骤为：对查询词进行分词，对分词进行hash，直接查询hash表格，获取doc_id的list，然后多个词进行合并。龙哥：没错，每个分词遍历一次trie树，可以得到doc_id的list，多个分词得到的list合并，就是最终的结果。龙哥：存内存操作，能满足很大的并发，时延也很低，占用内存也不大，实现非常简单快速。

答案是通过策略和配置。分流服务，它是推荐系统中一个非常有特色也非常重要的一个服务，它的作用是将上游过来的请求，按照不同的策略，以不同的比例，分流到不同的推荐算法实验平台（也就是下游的推荐内核）中去。该服务的实现要点是：实现一个通用的服务框架，让算法人员能够快速的生成module服务，并将自己的需求在module中实现，且能够在算法实验平台方便的进行module服务的调用。推荐内核，是各类线上推荐算法实施的核心，它其实只是一个通用的实验平台容器，每个推荐服务内部可能跑的是不同类型的推荐算法。

答：本地数据不能直接使用的原因是，不确定数据是否最新，拉取服务器时间戳与本地时间戳进行比对，如果本地是最新的数据，就能避免重新拉取。故，对于微信，登录时只需要拉取好友列表（id+name）与群组列表（id+name）即可，而其他数据，等用户真正点击和使用时再拉取即可，这样就可以大大减少拉取流量。（2）“服务端”收到客户端上传的时间戳，与最新时间戳对比，找出差异，假设有10个好友的信息发生了变化，服务端可以直接将有差异的10个好友的数据返回。答：不能直接复用客户端本地的数据，因为不能确保本地的数据是最新的。

既然bid*CTR是所有广告综合打分的依据，且 出价bid又是广告主事先设定好的，那么实际上，广告排序问题的核心又转向了广告CTR的预测， CTR预测是推荐系统、广告系统、搜索系统里非常重要的一部分，是一个工程，算法，业务三方结合的问题，本文就不展开讨论了。展示了广告后，展现端js会上报广告 展示日志，有部分用户点击了广告，服务端会记录 点击日志，这些日志可以作为广告算法实施的数据源，同时，他们经过统计分析之后，会被展示给广告主，让他们能够看到自己广告的展示信息，点击信息。

这个线程模型应用很广，符合大部分场景，这个线程模型的特点是，工作线程内部是同步阻塞执行任务的（回想一下tomcat线程中是怎么执行Java程序的，dubbo工作线程中是怎么执行任务的），因此可以通过增加Worker线程数来增加并发能力，今天要讨论的重点是“该模型Worker线程数设置为多少能达到最大的并发”。3）通常来说，Worker线程一般不会一直占用CPU进行计算，此时即使CPU是单核，增加Worker线程也能够提高并发，因为这个线程在休息的时候，其他的线程可以继续工作。

通过压力测试发现，web层是瓶颈，tomcat压测单机只能抗住1200的QPS（一般来说，1%的流量到数据库，数据库500QPS还是能轻松抗住的，cache的话QPS能抗住，需要评估cache的带宽，假设不是瓶颈），我们就得到了web单机极限的QPS是1200。举例：58要做一个APP-push的运营活动，计划在30分钟内完成5000w用户的push推送，预计push消息点击率10%，求push落地页系统的总访问量？系统容量规划时，不能只考虑平均QPS，而是要抗住高峰的QPS，如何知道高峰QPS呢？

ID生成服务假设每次批量拉取6个ID，服务访问数据库，将当前ID的最大值修改为5，这样应用访问ID生成服务索要ID，ID生成服务不需要每次访问数据库，就能依次派发0,1,2,3,4,5这些ID了，当ID发完后，再将ID的最大值修改为11，就能再次派发6,7,8,9,10,11这些ID了，于是数据库的压力就降低到原来的1/6了。（1）丧失了ID生成的“绝对递增性”：先访问库0生成0,3，再访问库1生成1，可能导致在非常短的时间内，ID生成不是绝对递增的（这个问题不大，我们的目标是趋势递增，不是绝对递增）

这就是所谓的“将请求尽量拦截在系统上游”，越上游越好，浏览器层，APP层就给拦住，这样就能挡住80%+的请求，这种办法只能拦住普通用户（但99%的用户是普通用户）对于群内的 高端程序员是拦不住的。好，这个方式拦住了写for循环发http请求的程序员，有些高端程序员（黑客）控制了10w个肉鸡，手里有10w个uid，同时发请求（先不考虑实名制的问题，小米抢手机不需要实名制），这下怎么办，站点层按照uid限流拦不住了。回想12306所做的，分时分段售票，原来统一10点卖票，现在8点，8点半，9点，…