动机和激励是绩效管理的核心。没有激励，员工没有动机把事情做好，所有的反馈和培训都是白费力气。
领导对员工的尊重与员工的激励程度正相关
冒犯行为会直接打击员工的动机和绩效，所以经理需要遏制冒犯行为，可以这样做：
- 自己作出表率，上行下效。
- 维护员工的自尊。公开表扬，私下批评。
- 雇佣尊重人的员工，不姑息坏行为。遇到问题反馈要及时。
激励主要来自两个方面：外在和内在
-
外在的奖励——金钱 （升职加薪奖金）
- 这种奖励不一定会提高员工的绩效。
- 通常效果短暂。
- 整个团队的工作很难分清楚贡献的多寡，奖励多少才算合适对每个人来讲标准都不一样。实际上，大多数员工的主要关注点在于公平，作出金钱奖励的时候一定要注意公平性和一致性(consistency)。
-
内在的奖励——满足感（成就感、控制感、被感激感、智力上的提升、技能提高、自治、达成挑战）
- 一定要注意，这种奖励要注意因人而异。
怎么做到给人以内在奖励呢？
-
认可他的工作。“认可的关键在于让人感受到他的与众不同”。每个人得到同样的东西，每个人就不会有与众不同感。
- 每个人对认可的来源的重视程度不同。来自同事？在同事面前公开表扬他。来自客户？发一张客户的感谢信。来自专业？发专业奖项。来自老板？1:1 的时候生动地描述他对团队的重要性。
- 按照性格认可。内向外向？公开私下？如果不清楚，可以直接问对方。
- 认可的频率要高，至少两周一次。
- 手写的奖励成本低但是效果奇佳。
-
提供决策权
- 人们喜欢拥有感和控制感
-
提供挑战
- 挑战难度越高，完成的成就感就越高。
- 提供做没做过的事情的机会，帮助人开发新技能。要注意，前提是他们有相关的天赋和技能，而不是完全从零开始。
公司
- 总共成立四年，前两年都在写代码，最近一年半有一两百家企业在用
- Infra 在中国做很有优势，因为中国市场大，公司快糙猛拿来主义，infra 的好东西能够很快地被用上
- cofounders 里面没有 db 的经验
- open source 模式是未来，如果是闭源只能一家一家谈
- 最重要的商业决策：不在于算法有多nb 团队有多厉害，护城河的关键在于 1）社区 2）mysql 接口 (借用了 mysql 的社区开始，SQL 的支持很重要，比如连Kafka, Spark都支持 SQL )
TiDB 数据库原理
越nb的工程师越喜欢高性能，认为越快越好。但是 TiDB 的首要目标不是做到最快，而是做到 Availability reliability 稳定性 IO和 无限扩展。高性能的成本太高，要根据用户的硬件优化。但是这里是通用的数据库，不可能去优化各种场景。简单留给用户，复杂留给自己（跟AWS意见相反）。
认为 eventual consistency 是个伪概念，实际上就是没一致性或者弱一致性。比如 cassandra WRN 设置好了，但到底过多久 能够resolve？不确定。太复杂，用户最好不需要知道操心这些复杂的设置。
跑分不是唯一的指标，TPCC/TPCH 分数高对实际没有太多指导意义。数据库是磨出来的。比如第一家客户，游戏公司，居然创建了3万张表，json 的 meta 信息连起来非常慢。
构架上不是 P2P，而是不同角色分得很清楚。
KV 用的是 RocksDB 但是典型的 LSM tree 的写放大是15倍，这里优化到 value 拆出来，解决写放大的问题。
支持 MySQL 的client，也支持 SparkSQL 的读。
SQL layer 没有用 MySQL 的模块。一开始有试过，但是1）下面很难分布式 2）代码太烂很难改。魔改的话，半年能做；但是长期的维护成本更高。重做不麻烦，都重构了三次了。这里用 Go 比用 C/C++/Rust 重构更方便。
一开始只想做 F1只做sql，和 CockroachDB 合作，后来他们往sql这边做，这边就只能往storage 做
挖了 Rust core team 的两个人。rust 很难招人，一般是招 C++的人然后转rust，他们会觉得很多脑袋里的约定编译器帮你搞定了。
不要低估造工业级轮子的难度。用 grpc，raft，rocksdb的好处是，如果业界有新的进展，会直接让使用者收益。
Chunk (region) split 做了两个月，merge 做了三年。merge 做了形式化证明。
Tech 趋势
为什么是现在？
- hardware
- Hot / cold data -> warm data
- Log is the new database
Everything is pluggable , 顶层 api 不变，下面即插即用可替换
Distributed Transaction
- 2PC is the only option
- challenges: reduce round-trips
Multi-tenancy achieved by kubernetes
中国 Biz Trend
- 中国速度，说上就得上
- 对新技术服务赋能业务的期望更高。二三线城市的公司或者非BAT用新技术与巨头斗争。必须能够解决使用者的技术焦虑。
- 基础软件人才储备逐渐变强。P产能CAP 对技术 content marketing 做了很多贡献。
- 一些核心场景（银行核心系统）敢于使用国产技术。
- PingCAP路径：开源（互联网/社区） <-> 商业化
为什么有这种框架？
- 为了在更短的时间内处理更多的数据。
- 统一处理分布式系统中的容错问题。
- 将任务简化抽象以应对多变的业务要求。
- 分别适用于有界数据集（批处理）和无界数据集（流处理）。
批处理与流处理的发展史简介
- Hadoop 与 MapReduce。谷歌让批处理在一个分布式系统中像 MapRduce
result = pairs.map((pair) => (morePairs)).reduce(somePairs => lessPairs)一样简单。 - Apache Storm 与有向图拓扑结构。MapReduce 不能很好地表示迭代算法。因此，内森·马兹（Nathan Marz）将流处理抽象成一个由 spouts 和 bolts 组件构成的图结构。
- Spark 内存计算。辛湜（Reynold Xin）指出 Spark 在处理相同数据的时候比 Hadoop 少使用十倍机器的同时速度却快三倍
- 基于 Millwheel 和 FlumeJava 的谷歌数据流（Google Dataflow）。谷歌使用窗口化API同时支持批处理与流处理。
等等…那么为什么 Flink 变得如此热门？
- Flink 快速采纳了 Google Dataflow 以及 Apache Beam 的编程模式。
- Flink 对 Chandy-Lamport checkpointing 算法的高效实现。
这些框架
架构选择
若要用商业机器来满足以上的需求，有这些热门的分布式系统架构……
- master-slave（中心化的）：Apache Storm + zookeeper， Apache Samza + YARN
- P2P（去中心化的）：Apache s4
功能
- DAG Topology 用来迭代处理 -例如Spark 中的 GraphX， Apache Storm 中的 topologies， Flink 中的 DataStream API。
- 交付保证 (Delivery Guarantees)。如何确保节点与节点之间数据交付的可靠性？至少一次 / 至多一次 / 一次。
- 容错性。使用cold/warm/hot standby, checkpointing 或者 active-active 来实现容错。
- 无界数据集的窗口化API。例如 Apache 的流式窗口。Spark 的Window函数。Apache Beam 的窗口化。
不同架构的区别对照表
| 架构 | Storm | Storm-trident | Spark | Flink |
|---|---|---|---|---|
| 模型 | 原生 | 微批量 | 微批量 | 原生 |
| Guarentees | 至少一次 | 一次 | 一次 | 一次 |
| 容错性 | 记录Ack | 记录Ack | 检查点 | 检查点 |
| 最大容错 | 高 | 中 | 中 | 低 |
| 延迟 | 非常低 | 高 | 高 | 低 |
| 吞吐量 | 低 | 中 | 高 | 高 |
免责声明：以下所有内容均来自公共资源或纯粹原创。 这里不包含优步的涉密内容。
要求
- 为全球的交通运输市场提供服务
- 大规模的实时调度
- 后端设计
架构
为何要微服务？
Conway定律 软件的系统结构会对应企业的组织结构。
| 单体 服务 | 微服务 | |
|---|---|---|
| 当团队规模和代码库很小时，生产力 | ✅ 高 | ❌ 低 |
| 当团队规模和代码库很大时，生产力 | ❌ 低 | ✅ 高 (Conway定律) |
| 对工程质量的要求 | ❌ 高 (能力不够的开发人员很容易破坏整个系统) | ✅ 低 (运行时是隔离的) |
| dependency 版本升级 | ✅ 快 (集中管理) | ❌ 慢 |
| 多租户支持 / 生产-staging状态隔离 | ✅ 容易 | ❌ 困难 (每项服务必须 1) 要么建立一个staging环境连接到其他处于staging状态的服务 2) 要么跨请求上下文和数据存储的多租户支持) |
| 可调试性，假设相同的模块，参数，日志 | ❌ 低 | ✅ 高 (如果有分布式tracing) |
| 延迟 | ✅ 低 (本地) | ❌ 高 (远程) |
| DevOps成本 | ✅ 低 (构建工具成本高) | ❌ 高 (容量规划很难) |
结合单体 代码库 和微服务可以同时利用两者的长处.
调度服务
- 由geohash提供一致的哈希地址
- 数据在内存中是瞬态的，因此不需要复制. (CAP: AP高于CP)
- 分片中使用单线程或者锁，以防止双重调度
支付服务
关键是要有异步设计, 因为跨多个系统的ACID交易支付系统通常具有非常长的延迟.
- 利用事件队列
- 支付接口集成 Braintree, PayPal, Card.io, Alipay 等
- 通过详尽的 log 来记录所有 event
- 使用具有等幂性、指数退避和随机抖动的API
用户档案服务和行程记录服务
- 使用缓存降低延迟
- 随着 1) 支持更多的国家和地区 2) 用户角色（司机，骑手，餐馆老板，食客等）逐渐增加，为这些用户提供用户档案服务也面临着巨大的挑战。
通知推送服务
- 苹果通知推送服务 (不可靠)
- 谷歌云消息服务GCM （它可以检测到是否成功递送) 或者
- 短信服务通常更可靠
安迪格鲁夫强调：管理者最重要的责任是激发他的下属做出最佳的表现。
不幸的是，没有一种管理风格适合各种场景下的所有人。找到最佳管理风格的基本变量是下属的任务相关成熟度（TRM）。
| 部属的工作成熟度 | 有效的领导风格 |
|---|---|
| 低 | 组织化; 以任务为导向; 面向细节; 准确地指出“什么时候-什么事情-怎么做”的细节模式 |
| 中 | 以人为本; 给予支持，“双向沟通”模式 |
| 高 | 以目标为导向的“监控”模式 |
一个人的任务相关的成熟度取决于具体的工作项目，它的改进需要时间。 当任务相关的成熟度达到最高水平时，这个人的知识水平和积极性就会达到一定高度，让他的管理者能够顺利地把工作委派给他。
这其中的关键是管理方式无所谓好坏，只有有效和无效。
