1. 针对几百或一千个关键人物，而不是数百万人
   1. 例如，Dropbox在首次发布时以一个有趣的演示视频开始。人们可以注册但需要等待使用它。用一些==新颖且令人兴奋的==东西来吸引用户
   2. 又如，2012年eBay与Gogo合作，在航班飞行期间提供免费无线网络连接ebay.com。它的高明之处在于可以跟踪数据，通过看它是否有益来决定是否继续合作
2. 不要针对所有人 - 针对合适的人
   1. 例如，优步为奥斯汀的西南偏南会议提供了多年的免费乘车服务，这一举措吸引了成千上万的年轻且有高收入的技术爱好者
   2. 小技巧
      • 说服媒体网站写关于自己的内容
      • 在Hacker News, Quora 和 Reddit上发表帖子
      • 写博客
      • 使用Kickstarter众筹
      • 通过 www.helpareporter.com 来联系记者
      • 免费或通过一些奖励来邀请用户
   3. ==大技巧==
      • 用“仅限邀请”创造排他性的饥饿营销
      • 创建虚假用户以使其更加活跃。 （Reddit采用了这种方法）
      • 专注于单一平台（PayPal和eBay）
      • 逐个用户群组扩散到另一个用户群组（Facebook和大学）
      • 吸引有影响力的人，因为他们有广大的受众和良好的声誉
      • 在电子商务网站的子域上做慈善捐赠（Amazon）
3. 专注于新用户注册（获取）而非品牌意识
4. 增长技术 = 市场营销 + 工程
   1. 例如，爱彼迎（Airbnb）制作工具同时向 Craigslist 交叉发布帖子
   2. 肖恩·埃利斯曾经说过:“坚持专注于获取客户而不是'创造品牌意识'往往需要克制... 诚然，如果公司到了一定规模，品牌意识/品牌建设是有意义的。但是，在最初的一两年内这就完全是在浪费钱”
   3. 无效的行为
      1. 盛大的发布
      2. 一厢情愿地认为，桃李不言，下自成蹊 （而亚伦·斯沃茨认为，用户必须被吸引才会来）

增长黑客的四个步骤​

1. 从产品市场契合（PMF）开始
2. 找到你的增长黑客
3. 实现病毒式传播
4. 完成闭环

如何开始产品市场契合（PMF）？​

1. ==产品/市场契合== 是指产品满足强烈市场需求的程度。

2. 从最小可行产品（MVP）开始，并通过反馈不断演进

3. 利用数据和信息来支持PMF。

4. 尽早了解客户的需求

   1. 例如，亚马逊员工在开发项目之前会发布内部新闻稿以收集反馈。
   2. 例如，维尔纳·沃格尔建议为你正在开发的产品编写常见问题解答/关键用户体验/用户手册 = 概念 + 使用方法 + 参考

5. 运用苏格拉底的方法来发展答案

   1. 这个产品是给谁的？他们为什么会使用它？我为什么使用它？
   2. 是什么让你选择这个产品？是什么阻止你推荐给其他人？缺少什么？最重要的是什么？

设计一个系统，可以将用户给的网址变成短网址，用户使用这些短网址可以访问他们原来给的网址（下面简称长网址）。描述这个系统是怎么运作的，需包括但不限于下面的问题：怎么分配短网址？怎么存储短网址和长网址的映射关系？怎么实现跳转服务？怎么存储访问数据？

假设：在一开始的问题描述中不包含这些假设。一个优秀的面试者在得到一个具体设计的时候会问关于系统规模的问题。

• 长网址的域名大概有上万个
• 新的长网址流量大概是 10,000,000/天 （100/秒）
• 使用短网址访问长网址的跳转服务的流量大概是 10B/天 （100,000/秒）
• 提醒面试者这些是平均数字 - 在一些高峰期的时候这些数字会大很多（一种时间导致的高峰期，比如用户刚工作完回家的时候， 另一种是事件导致的高峰期，比如春节联欢晚会的时候）
• 最近的数据（比如今天的数据）应该被提前收集好，并且在用户想要看的时候可以在五分钟内得到。
• 每天计算历史数据

假设​

每天有1B新网址，100B的短网址访问 短网址越短越好 数据的展示（实时/每天/每个月/每年）

网址编码​

http://blog.codinghorror.com/url-shortening-hashes-in-practice/

方法1. md5(128位，16个16进制数字，冲突，生日悖论，2^(n/2) = 2^64) 再短一些？（64位，8个16进制数字，冲突 2^32）, 64进制。

• 优点：哈希比较简单 而且 易于横向拓展。
• 缺点：太长，怎么去处理过期的网址？

方法2. 分布式的序号生成器。(62进制: az, AZ, 0~9, 62种字符, 62^7), 分区：每个节点包含一些序号。

• 优点：容易淘汰过期的网址，网址更短
• 缺点：不同分区之间的协调（zookeeper)

键值（KV）存储​

MySQL(10k 每秒访问量，慢，没有关系不需要关系型数据库)，键值（100k 每秒访问量，Redis, Memcached）

一个优秀的面试者会问关于短网址的预期使用期限，设计一套系统可以自动清理已经过期的短网址。

跟进​

问题：怎么生成短网址？

• 一个差的面试者 会提议用一个id生成器（单点故障）或者要在每个id生成的时候需要id生成器之间协同合作。 举例，使用自动增值的主键（auto-increment primary key）的数据库。
• 一个可以接受的面试者 会提议用md5，或者一些UUID生成器可以在一些结点上自己生成id的。这些方法可以在分布式系统上生成不冲突的ID，所以可以生产大量的短网址。
• 一个优秀的面试者 会设计一个方法利用一些id生成器，每个生成器先从中央协调器（例如ZooKeeper）保留一块id序列，这些id生成器可以单独从他们的id序列中分配id，有必要的时候在自己的id序列中做一些清理。

问题：怎么存储长网址和短网址之间的映射关系？

• 一个差的面试者 会建议使用一个单一的，非分布式，非关系型的数据库。它只是一个单纯的键值数据库。
• 一个优秀的面试者 会建议用简便的分布式系存储，例如 MongoDB/HBase/Voldemort 等。
• 一个更优秀的面试者 会问关于短网址的预期使用周期，然后设计一套系统==可以清理过期的短网址==。

问题：怎么实现跳转服务？

• 一个差的面试者 会从头开始设计这套系统来解决已经被解决的问题
• 一个优秀的面试者 会建议使用一个现成的HTTP服务器加上一个插件，用这个插件来翻译这个短网址的id，在数据库中找这个id，更新访问数据，返回303，跳转到长网址。 现成HTTP服务器比如 Apache/Jetty/Netty/tomcat 等。

问题：怎么存储访问数据？

• 一个差的面试者 会建议每次访问都写到数据库。
• 一个优秀的面试者 会建议由几个不同部分去做这件事情==生成访问流数据，收集整理，每过一段时间写到永久数据库中==。

问题：怎么分上一个问题优秀面试者提出的存储访问数据的不同部分？

• 一个优秀的面试者 会建议用一个延迟较低的信息系统去暂时存储访问数据，然后将数据交给收集整理部分
• 面试者可能会问访问数据多久需要被更新一次。如果每天更新，一个比较合理的方法是存储在HDFS，用map/reduce去计算数据。 如果是要近乎实时的数据，收集整理的部分就要计算出所需的数据

问题：怎么阻止访问受限的网站？

• 一个优秀的面试者 会要求在键值数据库里维护一个域名的黑名单。
• 一个好的面试者 可能会提出一些先进的技术， 可以用在系统规模变得很大的情况下， 比如bloom filter。

失效转移：失效转移（failover）是一种备份操作模式，用于提高系统稳定性和可用性。当主要组件由于失效或预定关机时间的原因而无法工作时，这种模式中的系统组件（如处理机、服务器、网络或数据库）的功能被转嫁到二级系统组件。

冷备份:冷备份是将关键性文件拷贝到另外的位置的一种说法，使用特征或指标/警报来跟踪故障。系统在发生故障时提供新的备用节点，当然，冷备份仅适用于无状态服务。对于备份Oracle数据库而言，冷备份是最快和最安全的方法。

热备份:保持两个活动系统承担相同的任务角色，也就是系统处于正常运转状态下的备份。两个系统中数据几乎是实时镜像的，且拥有相同的数据。

温备份:保持两个活动系统，除非发生故障，否则次要系统不占用流量。

检查点(或类似于Redis快照):系统在处理任务之前使用预先写入（write-ahead）日志(WAL)记录请求。备用节点在故障转移期间从日志中恢复。

• 缺点
  • 大量的日志恢复起来很耗时
  • 自上次检查点以来丢失数据
• 用户案例:Storm, WhillWheel, Samza

双主机(或全部主机)模式:将两个活动系统保留在负载平衡器之后。主机之间是平行的，且数据复制是双向的。

冷备份：使用心跳或指标/警报来跟踪故障。当发生故障时，配置新的备用节点。仅适用于无状态服务。

热备份：保持两个活动系统承担相同的角色。数据几乎实时镜像，两个系统将拥有相同的数据。

温备份：保持两个活动系统，但第二个系统在故障发生之前不接收流量。

检查点（或类似于 Redis 快照）：使用预写日志（WAL）在处理之前记录请求。备用节点在故障转移期间从日志中恢复。

• 缺点
  • 对于大型日志来说耗时较长
  • 自上次检查点以来丢失数据
• 使用案例：Storm、WhillWheel、Samza

主动-主动（或全活动）：在负载均衡器后保持两个活动系统。它们并行处理。数据复制是双向的。

设计一个系统，将用户提供的网址转换为缩短的网址，并重定向回原始网址。描述系统的工作原理。你将如何分配缩短的网址？你将如何存储缩短网址与原始网址的映射？你将如何实现重定向服务器？你将如何存储点击统计数据？

假设：我通常不会在初始问题陈述中包含这些假设。优秀的候选人会在提出设计时询问规模。

• 注册重定向网址的独特域名总数大约在数万左右
• 新网址注册量约为 10,000,000/天（100/秒）
• 重定向请求量约为 10B/天（100,000/秒）
• 提醒候选人这些是平均数字 - 在高峰流量时（例如“人们下班回家时”或“超级碗期间”）可能会高得多。
• 最近的统计数据（在当前日期内）应聚合并在 5 分钟延迟后可用
• 长期回顾统计数据可以每天计算

假设​

每天 1B 新网址，总共 100B 条目 越短越好 显示统计数据（实时和每日/月度/年度）

编码网址​

http://blog.codinghorror.com/url-shortening-hashes-in-practice/

选择 1. md5（128 位，16 个十六进制数字，碰撞，生日悖论，2^(n/2) = 2^64）截断？（64 位，8 个十六进制数字，碰撞 2^32），Base64。

• 优点：哈希简单且水平可扩展。
• 缺点：太长，如何清理过期网址？

选择 2. 分布式序列 ID 生成器。（Base62：az，AZ，0~9，62 个字符，62^7），分片：每个节点维护一部分 ID。

• 优点：易于淘汰过期条目，更短
• 缺点：协调（zookeeper）

KV 存储​

MySQL（10k qps，慢，无关系），KV（100k qps，Redis，Memcached）

优秀的候选人会询问别名的生命周期，并设计一个系统来清理过期的别名。

后续问题​

问：如何生成缩短的网址？

• 一个差的候选人会提出一个使用单一 ID 生成器的解决方案（单点故障）或一个在每个请求中需要协调 ID 生成器服务器的解决方案。例如，使用自增主键的单一数据库服务器。
• 一个可接受的候选人会提出使用网址的 md5，或某种形式的 UUID 生成器，可以在任何节点独立完成。虽然这允许分布式生成不冲突的 ID，但会产生较大的“缩短”网址。
• 一个优秀的候选人会设计一个解决方案，利用一组 ID 生成器，从中央协调器（例如 ZooKeeper）保留 ID 空间的块，并独立从其块中分配 ID，必要时刷新。

问：如何存储映射？

• 一个差的候选人会建议使用单体数据库。这个存储没有关系方面。它是一个纯粹的键值存储。
• 一个优秀的候选人会建议使用任何轻量级的分布式存储。MongoDB/HBase/Voldemort 等等。
• 一个优秀的候选人会询问别名的生命周期，并设计一个系统来==清理过期的别名==。

问：如何实现重定向服务器？

• 一个差的候选人会从头开始设计某种东西来解决一个已经解决的问题。
• 一个优秀的候选人会建议使用现成的 HTTP 服务器，配备一个插件，解析缩短的网址键，在数据库中查找别名，更新点击统计并返回 303 到原始网址。Apache/Jetty/Netty/tomcat 等等都可以。

问：点击统计数据如何存储？

• 一个差的候选人会建议在每次点击时写回数据存储。
• 一个优秀的候选人会建议某种形式的==聚合层，接受点击流数据，聚合并定期写回持久数据存储==。

问：如何对聚合层进行分区？

• 一个优秀的候选人会建议使用低延迟消息系统来缓冲点击数据并将其传输到聚合层。
• 一个候选人可能会询问统计数据需要多频繁更新。如果是每日更新，将其存储在 HDFS 中并运行 map/reduce 作业来计算统计数据是一个合理的方法。如果是近实时的，聚合逻辑应计算统计数据。

问：如何防止访问受限网站？

• 一个优秀的候选人可以回答通过在 KV 存储中维护一个主机名黑名单。
• 一个优秀的候选人可能会提出一些高级扩展技术，如布隆过滤器。

为什么选择 Lambda 架构？​

为了解决大数据带来的三个问题

1. 准确性（好）
2. 延迟（快）
3. 吞吐量（多）

例如，传统方式扩展页面查看服务的问题

1. 你从传统关系数据库开始。
2. 然后添加一个发布-订阅队列。
3. 然后通过水平分区或分片进行扩展。
4. 故障容错问题开始出现。
5. 数据损坏发生。

关键点是 ==AKF 规模立方体 的 X 轴维度单独并不足够。我们还应该引入 Y 轴 / 功能分解。Lambda 架构告诉我们如何为数据系统做到这一点。==

什么是 Lambda 架构？​

如果我们将数据系统定义为

查询 = 函数（所有数据）

那么 Lambda 架构是

批处理视图 = 函数（批处理作业执行时的所有数据）
实时视图 = 函数（实时视图，新数据）

查询 = 函数（批处理视图，实时视图）

==Lambda 架构 = CQRS（批处理层 + 服务层） + 快速层==

为什么要使用lambda架构？​

为了解决大数据所带来的三个问题

1. 准确性（好）
2. 延迟（快）
3. 吞吐量（多）

例如：以传统方式扩展网页浏览数据记录的问题

1. 首先使用传统的关系数据库
2. 然后添加一个“发布/订阅”模式队列
3. 然后通过横向分区或者分片的方式来扩展规模
4. 容错性问题开始出现
5. 数据损坏(data corruption)的现象开始出现

关键问题在于AKF扩展立方体中，==仅有X轴的水平分割一个维度是不够的，我们还需要引入Y轴的功能分解。而 lambda 架构可以指导我们如何为一个数据系统实现扩展==。

什么是lambda架构​

如果我们将一个数据系统定义为以下形式：

Query=function(all data)

那么一个lamda架构就是

batch view = function(all data at the batching job's execution time)
realtime view = function(realtime view, new data)

query = function(batch view. realtime view)

==lambda架构 = 读写分离(批处理层 + 服务层) + 实时处理层==

为什么要非暴力沟通？​

通过==重视每个人的需求==来提高沟通质量。==而猜疑和暴力是没能满足需求的表现==。

NVC不是什么​

• 不是为了表现友善。
• 不是为了让别人做我们想做的事情，这关乎于人与人之间的相互理解。

加强人与人之间联系和理解的方法​

1. 脆弱的表达出我们的感情和需求
   • 意识到持续的感情和需求
   • 暴露感情和需要的脆弱性
2. 着重听取对方的感情和需求
   • 共情聆听的核心:存在、专注、空间与关怀，==以及对感觉和需求的言语表达==
   • 不提建议，不做处理，不安慰，不讲故事，不同情，不做分析，不做解释，......
   • 无论说的什么，关键是听取对方的感受，需求，意见和要求

例如：==因为你需要......所以你觉得......?==

做这些事会导致我们之间彼此疏远​

• 对他人做评价，做判断，打标签，做分析，批评，对比，等等。
• 值得思考（即某些行为值得惩罚或奖励）
  • 要求（不接受他人的选择；想要惩罚那些不按照自己想法做的人）
  • 拒绝选择或承担责任（关键词：不得不，本应该，猜想会，他们让我做的，等等）

KYC (了解你的客户)并不容易​

==你多久才能有一次机会听你的客户描述他们遇到的问题？== 如果你是一家大公司的非市场部门雇员，答案是可能永远没有机会。

当然，如果你有机会，要知道在==买家人设核心概念==中有两个非常重要的部分

1. 询问探索性问题
2. 倾听

==KYC (了解你的客户)== 并不容易。例如：2008年，iPhone 3G在日本销售的情况不佳。而日本消费者习惯于用手机拍摄视频，用借记卡/火车通行证支付。

只拥有买家侧画是不够的​

一份普通的买家侧画 (buyer profile) 无法让营销人员准确的了解买家决定是否购买。营销人员只是根据人口统计（如年龄，收入，婚姻状况，教育）或心理特征（个性，价值观，生活方式，意见）对买家进行猜测。

尽管如此，买家简介仍能给出一些显而易见的答案。例如，通过电子邮件活动联系到首席财务官（CFO）是很困难的。而对于一个只有时间养金鱼的女人来说，强调汽车的货物空间即使放上大型犬也是很宽敞是没用的。

建立买家角色模型最有效的方式可不是猜测，而是调查那些曾经权衡过他们的选择、考虑过或拒绝过提出的解决方案，并做出了类似于你想要影响的决定的买家。

买家画像 = 买家侧画 buyer profile（谁会购买）+ 买家洞见 buyer insights（何时/如何/为什么购买）