是拉新，也是促活，因为你看到通讯录的好友也在使用抖音，你会添加他们为好友，或是邀请他们来抖音，分享好玩的视频。这是拉新；而一旦大家在抖音上面成为朋友，黏度增加，也是促活的表现。

邀请QQ，微博的好友一起玩

至于视频画面提升，这种也可以算作促活领域，因为用户体验变好了，自然用户继续使用的意愿就增强了，达到了促活的目的，不过这种小的动作，这里就不再多提啦。

标准的拉新行为，可以站外分享，从而将用户拉回来

新增附近功能，发现身边有趣的人：

促活动作：当用户可以看到周边的人状态，会更有代入感，毕竟是周边的人，这样促使大家对于产品的活跃

2. 人人都是产品经理

从该网站中提到的内容，整理如下：

a. 添加qq好友，添加微信，添加微博

这些都是拉新动作，也是促活，通过邀请微信用户进行拉新，通过关注通讯录里面的人，看他们日常发送的内容，由于是朋友的内容，会更加愿意去看，起到一定的促活效果

抖音赞助了《中国有嘻哈》、《快乐大本营》和《天天向上》等这些受众相似的综艺，是标准的拉新动作。

c. 开通【直播问答】

通过引入「直播问答」的新风口，抖音迎来了第二波产品高速增长，通过借势，用户间的分享，起到拉新的作用，同时，一些之前看短视频的人，可以通过强互动的【直播问答】，达到促活的目的

每天推送几次关注的人的动态，或是没有关注的人，但点赞数比较好的内容

通过借势，发起当下流行的或比较容易火的挑战，来促使用户参与，例如：#奥斯卡欠你一座小金人#，激发了无数“戏精们”的模仿，起到了很好的促活效果

f. 抖音达人线下交流活动

如IDOU夜周年庆、城市嗨趴等为其提供更高的曝光度，更好的交流机会和粉丝互动机会，为抖音平台优质内容生产者提供持续创造优秀作品的条件。既是促活，也是拉新，拉新更多的是针对线下的流量开拓，促活是通过给优秀的抖音达人提供良好的内容创作环境，达到促活达人的目的，而达人创造了很好的内容后，也会促活很多喜欢他的粉丝。

g. 和网易云音乐互换资源

用户点击网易云音乐可以跳转到抖音app下载页面。起到拉新的作用。

通过引入明星和KOL的入驻，让更多的粉丝参与进来。拉新动作。

当好友@你的时候，自然你会大概率打开抖音，起到促活的作用。

增加了优质内容的供给，保证了用户的留存。

内涵段子推广，使抖音获得第一批种子用户。

对于开始没有人看的视频，通过机器人点赞，鼓励用户继续生产新的内容，是增加留存的方式

d. 评论区展现逻辑：

用户的评论可以被点赞，排序顺序是按照点赞高低展现的，用户打开评论区，会优先看到优质内容，增加了用户的体验，促进了留存。

4. 知乎，虎嗅，鸟哥笔记，艾瑞咨询，蝉大师等

由于篇幅有限，就不展开一一列出了，直接把剩下几个渠道汇总整理吧。

有很多关于抖音的互相鼓励拍摄的群，表面上看是用户自发组织的，但不乏很多也是抖音官方小号组织的。通过运营微信群，鼓励大家不断拍摄优质内容，指导大家获得更高赞，等等达到促活，留存的目的

根据网上提到的测试逻辑，5000播放为一个分水岭，100赞为一个界限。即：一个视频，如果没有过5000播放，很难变火，说明抖音分发逻辑在于：一个视频，如果赞/播放的比例较低，抖音不会继续推荐，它更倾向于推荐更优质的视频，保证用户持续关注，持续活跃，增加留存。

a. 视频可以分享到微博

是标准的拉新动作，也是分享动作。

每次打开抖音，推荐的都是点赞数量较多，评论较多的优质内容，内容质量保证了用户不会流失，而只有当你不断去刷，刷将近一小时以上，才可能刷出赞数很少，甚至是零赞的内容，这种分发逻辑都是确保用户不断上瘾，不断看优秀的内容，保证了用户活跃，也增加了用户的留存。

由于增加了变现的手段，（针对粉丝数较多的用户），很多大v因为可以挣到钱，就不太容易流失，而大v的内容直接决定了用户的观看时间和打开频次。所以，它也是增加留存的手段。

在上传视频方面，非常简化，拍摄视频后，也可以直接选择适合的音乐，加入相应的滤镜，剪辑视频，保证了用户的上传积极性，可以算作增加留存的方法

抖音做了很好的用户分层体系，比如：针对高端，高频的内容产出用户，抖音会派专门人员来维护，每次这些人发布内容，抖音都会给予高权重推荐，保证了高端用户的留存和相应粉丝的留存。

支持查找通讯录功能，邀请QQ，微博的好友一起玩，开通【直播问答】

节目赞助，抖音达人线下交流活动，网易云音乐互换资源，明星&KOL入驻，评论可以@好友，内涵段子拉新

新增附近功能，发现身边有趣的人，开通【直播问答】，抖音达人线下交流活动，

APP Push，不断发起挑战，抖音微信群，优化分发逻辑

抖音签约MCN机构，机器人点赞，评论区展现逻辑，优质内容展现，优化分发逻辑，用户分级运营。

变现电商，信息流广告，内容广告植入

支持分享到美拍等社交媒体，开通【直播问答】

微信群运营，内容引导转发

a. 类似内容推荐密度

有些相似内容，比如之前火的土耳其冰激凌，之后的重庆网红地，还有最近的宁哥，都是热推的内容，但是呢，推荐的密度过高，每刷10几条就会推荐一条同样主题的，用户会有点腻，可以考虑推荐一些不太一样主题的内容

抖音是竖版视频，建议针对横版广告内容进行降权，多推荐竖版广告，也反向建议广告主生产竖版广告，体验更好，用户观看可能性更高，抖音获得更多广告收入，三方得利。

有些视频很火，像是宁哥（唱歌达人），但是打开抖音以后就是他的视频，显得很突然，看评论也是，很多人都不知道这个人是谁，显得很突兀，用户可能就会快速略过，容易产生流失。

类似的内容是需要上下文的，比如先有一个视频告诉我他是一个唱歌的，之后再推类似他的见面会，用户有了头绪，就更容易继续活跃。

所以：需要运营人员分发的时候，不仅要先拣着优质内容推，还要选择用户不会产生疑惑的视频进行推荐。

对于有水印的内容，应该降权，甚至不予推荐，但是有些视频，完全没有涉及到政治，涉及到禁忌，最后也被删除，导致用户积极性下降，很容易流失。

或是即使不合格，可否有一个可以比较容易联系到抖音工作人员的联系方式，否则被枪毙得不明不白，就非常郁闷

首页下方第二个tab，都是已经关注的人，但此页体验不好，视频画面较小，另外，观看首页信息流的时候，已经关注的人会优先被推荐，所以我既然已经可以在首页看到他们，为什么还要单独去第二个tab看关注人的视频呢？感觉也有点鸡肋。

由于不知道具体的数据，具体产品建议还需要看到相关数据才行。

编者按：高可用架构分享及传播在架构领域具有典型意义的文章，本文由孙子荀分享。转载请注明来自高可用架构公众号 ArchNotes。

孙子荀，2009 年在华为从事内核和分布式系统的开发工作；2011 年在百度从事过高性能计算方面的工作；2012 年加入腾讯进行 QQ 群广告系统的开发，随后负责腾讯云加速的带宽调度系统的设计研发；2014 年开始手 Q 公众号后台设计开发。 腾讯优秀讲师，包括 Linux 内核的讲授，并行计算等课程。在内核、数据挖掘、计算机广告等方面有很深的造诣。

公众号是从去年底的开始开发，期间封闭开发半年时间，基础能力已经对齐微信，而且在其他领域有新的拓展。目前已经对腾讯系的业务开放，对外小范围开放。等待政府批文之后，将全面开放注册。

现在业务规模支撑百万公众号，关系链存储上T 。机器规模春节期间在数百台，有深圳天津两个中心，分散在十几个 IDC 机房。消息规模每天数十亿，支撑了手 Q 一半以上的日活，包括腾讯新闻、QQ 音乐、附近、天气、购物号、订阅号、兴趣号等，只要是手 Q 非个人好友，基本都是公众号。

我去微信进行授课的时候，和微信的同学做过交流，发现大家的技术挑战和问题的场景以及背景有着很大的不同，无法简单的在技术上无法复用。

这里举个例子：QQ 公众号的关系链设计之初是为了承载亿级的，这点和微博的收听关系很像。而微信现在在用 MySQL 集群的方式，主要都是万级别的关系链。亿级在支持高并发访问和 IDC 一致性的时候就更加有挑战。

QQ 公众号从开始就支撑公司内部的亿级 DAU 的业务，比如音乐、腾讯新闻、春节红包等这样的业务。 消息峰值在每秒数十万 。 而微信主要是对外，外部用户加起来很难达到这个量级。

今天受高可用架构邀请，主要介绍的是 QQ 公众号的群发子系统，也是公众号业务用使用频率最高的一个功能。

群发，无论是微信还是 QQ 公众号都是使用功能最多的业务。

在微信，群发只是公众号运营者对其关注者进行消息发送，然而在 QQ 公众号里面，群发需要支持非常多的复杂组合模式。 比如自定义号码包、关系链&分组、标签、人群定向等，这是千人一面。 现在我们也支持了千人千面的群发方式。

群发我们一共开发了 4 期，从基础设施到调度能力。现在是 5 期的发送效果改造（通过 pCTR 开始从营销往生态用户考虑）。这个过程我们在不断的抽象各种层次关系。

我们先说最简单的场景：关系链发送。我们通过关系链接口，拉取一批用户，发送一批。当然这个过程可以并行。到了后来有了业务方提供自己挖掘的号码包（腾讯基本各个大型业务都会有自己的挖掘团队）。然后我们发现可以复用这种方式，无非是针对不同底层存储（ NoSQL、文件或者 MySQL）实现一个 JDBC 那样的存储适配驱动，最终都是 getBatchFromxxx 、endBatchToxxx 。但是这样的系统，任务不能自己恢复，没有状态维护，发送和拉取严重耦合在一起，谁按照需求发展都不独立。

于是我们决定将所有的发送都收敛到号码包。无论来自哪个存储，都收敛到一个发送的号码包文件。通过文件解耦， 有了这个文件，就天然有了作业任务的一个输入条件，形成一个作业任务，交给作业系统。作业系统负责任务的调度分发、排队、self-heal 。

这个系统里面有像腾讯新闻一样，一次发送上亿用户的，而且要求峰值每秒数十万的速度，更多的有像订阅号那样一次发送几万，每秒并发几百个任务一起发送的。

在包处理层，我们处理各个需求，对于业务自己挖掘的号码包，我们做关系链过滤、CRC 过滤（不要重发）、频次配额过滤、黑名单过滤、定向条件过滤等等。

这里使用了一个 GoF 的责任链模式， 根据业务号的属性和当前的模式来决定到底需要开启哪些过滤器插件。

在这层根据包来源的介质，我们做了加速处理。

对于十几亿的粉丝，拉取时间受限于关系链的存储网络开销，业务机的带宽维持在 20Mbyte/s，就算并行也有时间浪费。我们希望永远不要因为预处理耽误时间。每次群发都有这么大的网络开销是十分可惜的。 

所以我们把超过千万的粉丝全量拉取到本地。同时受益于关系链变更的时候，我们会有专门的消息队列用于生产事件，各个需求模块监听按需处理，使得增量同步保证短时间的一致性也变得非常高效。于是我们设计了一个模块用于把大于某个粉丝级别的用户保存到本地，这里其实只需要保存二进制文件。 算一下 1亿 * 8byte 大约 760M 的样子。 这样对于 1T 的磁盘，单机就可以满足公众号 所有千万级以上号码的粉丝。

PS：在腾讯一直有一个思想叫一切皆可控，就是系统服务能力不是压测出来的，而是设计的时候，就清楚的知道单机的服务能力，根据网络模型、级联带宽、包大小处理能力等进行预估。这就需要设计的人有内核、应用层编程、技术选件的把握，要求挺高的，腾讯的后台 T4 才能有这个 level 。：）

对于加速文件，当集群机器过多的时候，如何保证的关系链文件已经存在集群中所有机器？

• 一种方式就是放在分布式文件系统上，然后本机定时从中拷贝出来，但是会导致 CFS 出口带宽压力。

• 一种就是通过 BT 来分发，我们团队之前是从事下载的，这个在旋风时代做的已经非常多了。通过 btsync 来做到内网搭建一个 DHT 网络进行 P2P 下载。速度非常快。

但是优化都可能导致引入新的问题。如果有粉丝剧烈的变化的情况，刚刚的优化其实是不可靠的。

于是这里我们坚持一定要进行实时的合理性校验。但是如果每个都去校验效率非常低，不实际甚至不如不优化。 我们通过抽样校验，随机抽取10份样本， 每次采样的数目范围在 [100,10000]， 具体是粉丝总数 / 1万，错误率控制在 10次错误率的算术平均值必须小于 2%，且单次不能超过 10% 。否则我们会放弃优化回源从原始的存储业务服务拉取。

说这个是希望大家知道任何优化可能都是有损的，还是要考虑可能的风险。

框架从设计的开始就有以下几个目标：

1. 分层，任意层都可以水平扩展。

就是对于任何运行的状态都能恢复，比如 Spark 的 check point 机制。我们所有的任务，在生命周期都通过腾讯的容灾 CDB 进行状态落地，任务文件都有流水保存。 任务都存放在 CDB 中作为一条作业，接口层和任务调度层之间通过我们设计的无主并行任务分配算法（Acentric Parallel Task Allocation）进行无损的任务分发（参考了思科的 OSPF ）。任务调度层的机器任意添加故障都不会导致任务丢失，而且并行进行任务的批量调度。在调度层和任务分发层以及执行层，通过 ZMQ 这样的消息组件进行消息传递。多生产和多消费者模式。

APTA 其实就是一致性HASH + OSPF 路由算法。 简单介绍如下：

首先作业集群中的机器有几种状态

ONLINE : 表示机器在线 ，已经被集群所有的机器知道。

JOINING: 表示机器刚刚进入集群，还没有被接受。

WORKING: 表示机器已经加入整个作业的分配中。

OFFLINE : 表示机器已经失去联系。且与任何机器都没有连接。

SILENCE: 静默状态，表示当前不进行任务的处理工作。

下面是集群的状态扭转图：

我们不需要一台作业进程所在的机器被集群中一半以上的机器认可，才能正常工作。 因为主要这台机器不脱离集群 ，和任意一个作业机器有网络连接。都可以存活在 作业集群中。 拥有处理作业任务的能力。

上面这种场景，蓝色机器是完全被接受的。因为他可以进行作业任务。

首先所有调用接口的任务都附属状态机，跟着任务的作业状态进行扭转。

由于执行作业的机器槽位永远小于需要被执行的任务，所以我们需要在调度层决定哪些业务可以被调度。在这里我们参考了 Linux 操作系统的优先级调度，对于每一个作业任务区分是实时作业还是非实时。

实时：紧急任务，无法被抢占。

根据公式得出一个任务的调度分，然后根据这个调度分来排入优先级队列。

任务离开调度层都开始真正的作业。第一步就是接受预处理，就是刚刚说号码包处理的逻辑。处理完毕之后就需要真正的发送了，我们在分发的接口层会评价任务需要的资源。然后根据下游执行机器上的 manger 程序上报的负载情况来决定如何进行任务拆分和资源的分配。

内存和任务的大小有关，CPU 网卡带宽的需求和发送速度有关。 速度如果业务没有权利设置，那就是我们根据全局的负载计算出来的。 受限于网卡的处理能力和下游服务器的处理能力，其实就是一个受限的最优化问题 。我们会优先选择单机的资源，如果单机得不到满足就拆分任务单元，放到多个机器进行发送。 这里看到和 yarn 不同，我们把业务调度和资源分配分在了不同层和阶段来解决，其实简化了问题。

我们没有用 Docker 这样的技术，感觉还没必要。但是在作业执行层，我们对于不同的作业有发送的网卡需求，有需要写 CFS 的网卡需求，为了保证有限网卡的独立性，我们通过 cgroup 的 net_cls 来分配业务进程的带宽。 使得同一机器上的不同进程资源不受影响。

补充一点，刚刚的状态机，在各个状态转换的时候，用了MySQL 的 trigger ，由专门的程序来处理，然后生产到消息队列给外围的系统，解耦开来。

为了保证一定的到达率，我们发送都是在线发送，只对在线的用户进行发送， 发送完毕在线的，这个作业就算结束了，对于用户没有在线那么我们就会发到这台机器上的一个leveldb ，形成一个链表，接入我们公司的用户登录触发组件。当用户登录了，就把用户身上的这个任务链表遍历，调用接口进行发送。

其实有了比较好的基础设施之后，容灾会变得简单。

群发核心挑战是深圳的任务如果执行一半失败了，是否能在天津恢复。 这里的核心问题就是数据如何同步。

首先我们群发每次发送的时候都会通过 hippo（腾讯的一款消息队列组件）进行上报。 原始的号码包保存在了深圳的 CFS 仓库。当作业失败了，天津具有了这个原始号码包文件，并且从 hippo 获得作业信息和发送的号码列表，diff 出差异文件，在天津重建余量的发送任务。如果深圳任务成功则删除该号码包文件。

单 IDC 问题就更简单了。任何时刻任务崩溃了，我们都可以正确的找到上一次执行的位置，然后重新建立一个任务，根据上一次执行的阶段，设置适合的状态，在状态机中重新触发相应的处理逻辑。

现在我们群发系统，我们除了工程上的技术优化以外，主要在整个效果控制的工程建设上进行。

为了使得我们平台能够良好的运转，用户不收到过多对用户没有价值的消息 。 我们和产品从各个纬度按照规则和背景制定了下面的控制手段。

配额 ，频次。 根据业务上一次投放的效果点击率 配合产品的运营策略 来 分配配额。

频控，决定一个 pCTR ，平台策略，新鲜度决定一个用户能收到什么样的消息。频次均匀随机释放，一天用户可以收到最多6条公众号消息。

为了防止系统出现 B 运营者，在第二天 11:45 的时候，直接建立第二天 0:00 分的任务（系统限制只能建立 15 分钟之后的任务）导致第二天释放的用户频次被立刻抢走（因为没有竞争）。 这种先到先得的方式使得整个公众号平台不能良性的运转， 所有B的运营者都争先恐后的建立任务，出现所谓的火车票抢票情况。

于是我们系统变成了在当天随机释放频次。一种简单的实现方式是：假设一天一个 C 受限制只能收到 6 条，那么可以从 0 点开始，每隔 4 小时（这个间隔称之为竞争区间）随机释放一个，这样一天 24 小时就释放了 6 条。

实际运行中我们早上 12 小时有 2 个竞争区间，释放 2 个 C 频次。下午 12 小时有 4 个竞争区间，释放 4 个频次。 当前竞争区间没有被消耗的频次自动保存到下一竞争区间。每个B的任务，只和当前竞争区间内将要发送的任务进行竞争。

1、刚才提到群发只给在线用户发，用户是否在线的查询是通过什么样的方式，这块有没有瓶颈？

这里我们对于用户上线有实时的收集，然后会放入消息队列，然后每台机器都会安装一个 bitmap 的共享内存，42 亿bit , 所以判断在线，只要访问共享内存就可以了。

2、系统的升级控制是怎么做的？多长时间可以完成升级？

我们所有的程序都有管理端口，需要升级了通过管理端口发出指令，业务程序完成自身作业之后，就会从集群中退出，然后开始升级的流程，升级完毕之后 在自动上线处理任务。是一个平滑的升级过程，全系统升级只需要发送指令即可。完成一次升级的时间，取决于当前系统任务的繁忙程度。

3、现在对于一条需要群发给上亿用户的消息，最快可以做到多长时间群发完？影响群发速度的瓶颈主要在哪一块？

春节上 10 亿的消息，我们用了 15 分钟，取决于机器数目，都是并行拆分，可以更快。事实上我们能做到秒级别。因为我们其实系统有一个预送达的策略，也就是实现发送到用户的终端，在时间到了之后，端进行统一展现，特别适合春节抢红包的场景。

4、发送时候可能不成功或用户刚好离线，这一块怎么处理的？

没有查询到的状态就进入了 leveldb 的发送任务列表，等到在线了之后，实时触发，只要用户打开手 Q 就会实时下发 。

5、上文提到离线用户是存在本地 leveldb，多个群发任务如果是分布在多机，这个文件怎么 merge ？用户上线时候怎么获取全部的离线消息？

leveldb 的数据来自于分布式文件系统的文件，所以其实只有一份。

6、这个 CFS 仓库是跨 IDC 的吗？如果深圳的机房出现问题，天津机房能获得号码包文件吗？

问题问的好，CFS 不跨机房，天津深圳是两个仓库，我们依赖 VLAN 专线进行两个仓库的同步。事实上我们明年会使用支持 geo 的分布式文件系统，ceph 或者 glusterfs 这里还在做验证。

7、这个群发系统会落地吗？比如手机端重装了，再打开的话是否能看到之前群发的消息？

这个依赖于终端的实现，从后台看只要用户阅读过消息，我们后台存储会被抹去，就不会再次下发的。

8、请问你们的任务的状态机有多大规模？

状态机的规模大概有 2 个状态空间，二十几种状态。中断之后都是秒级别恢复 。 任务一天的级别在几十万 这些都是可以水平扩展的。

9、听说微信一秒推送 1.2 亿，您的数据里峰值提到了数十万，这个差在哪？

微信消息通道机器规模是我们的 20 倍甚至更多。

10、每个人收到的消息频率是不一样的或者每个人消息内容不一样，发送的时候做这种过滤，数据量这么大怎么计算？

这里的计算量非常大。我们采用的是对于一个号码包进行并行的多线程处理拆分。发送的时候处理，统一在预处理层进行处理。 其实按照用户维度差不多是14亿用户， 每个用户的信息都存放在 leveldb 上，单机 1T 磁盘就可以 hold 住存储。leveldb 进行按照 hash 的拆分，可以把 CPU 性能榨干。

11、群发时有无流量控制？或者 QOS 级别？cgroup 的 netcls 能否具体一些？

12、群一般都有人数限制，比如1000，2000，这个更多的是考虑业务上再多也没啥意，还是技术上消息广播有压力？还有类似于聊天室可能没有人数上限这一说，比如一个主播有一千万的观众的弹幕聊天，这种推送和我们的群处理起来有区别吗？

聊天室应该在万级别，而且聊天消息推送的场景 应该类似一个广播写入用户的未读列表就可以了。是一个 Pull 的过程，群发是一个过亿的 Push 的过程 在 Push 之前并不知道要 Push 的对象 需要实时产生。

13、随机释放频次，会不会导致消息到达客户端的时间不一致？这种情况怎么处理？

不会不一致。消息到达客户端取决于公众化运营者设置的发送时间和持续时间。这个我们会严格遵守。

14、对于 iOS 是用长链接发送还是苹果的消息通知，如果中间经过苹果怎么保证不把苹果搞挂？

这里对于离线走的是苹果的 PUSH 通道，然后触发一次长链接拉取。但是我们没有遇到把他们搞挂的情况，对于营销性质的发送，我们会选择走预送达通道。

15、前面提到 IDC 之间数据同步，微信的分布式文件系统或分布式数据库是跨 IDC 的吗（如果跨 IDC ，对于 IDC 之间通讯时延有要求吧）？这一块能否介绍详细一点？

微信应该没有用 CFS，这个问题刚刚回答过，现在的 CFS 是不支持 geo 的，我们用了 VLAN 专线，我们正在测试 ceph 等文件系统进行替换。

16、刚才有提到定期增量文件，这个频率大概是多少？什么时候会做 merge？

实时 merge，收到一个增量就进行处理。 每天会通过 BT 同步全量。

17、想请教一下发送消息的状态是怎么控制的？是传统的那种在数据库设置发送表做的么？

状态先写入 ZooKeeper ，然后由总控程序从 ZooKeeper 获得已经确认的状态写入数据库。