昨天和朋友聊到爱情三角理论，下来专门查看了书面的说法。

美国心理学家斯腾伯格提出的爱情理论，认为爱情由三个基本成分组成：激情、亲密和承诺。
激情是爱情中的性欲成分，是情绪上的着迷；亲密是指在爱情关系中能够引起的温暖体验；承诺指维持关系的决定期许或担保。
这三种成分构成了喜欢式爱情、迷恋式爱情、空洞式爱情、浪漫式爱情、伴侣式爱情、愚蠢式爱情、完美式爱情等七种类型。
这个理论认为爱情是由三个基本组成部分所构成的，这三个部分分别是：激情，亲密以及承诺。这三个组成部分就好象三角形的三条边，所以，这个理论就被称为爱情的三角理论。

1．迷恋：这种爱情仅仅包含激情部分；
2．喜欢：这种爱情仅仅包含亲密成分；
3．空爱：这种爱情仅仅有承诺成分；
4．浪漫之爱：这种爱情将亲密与激情结合在一起；
5．友谊之爱：这种爱情将亲密和承诺结合在一起；
6．愚蠢的爱：这种爱情将激情和承诺结合在一起；
7．没有爱：这里三种成分都没有；
8．完整的爱：这里三种成分都具备。

我们聊的时候没有这么多的大道理，而是选取了一些容易想到的词汇放在了这三个维度，话题是这三个维度似乎只能同时拥有两个，大意如下图，无关性别。

说到这的时候，我第一时间想到的是分布式系统的经典理论 —— CAP 原则，即在一个系统里一致性（Consistency）、可用性（Availability）、分区容忍性（Partition Tolerance），只能同时满足两点，不能三者兼顾。CAP 原则大到分布式系统的设计，小到我们平时做技术选型都有重要的指导意义。你是要强一致性还是要高可用，弄清楚自己的需求和方向非常重要，否则设计出来的系统就是既复杂又逻辑割裂的。从实现上来讲，要高可用，响应快嘛，那自然要牺牲一致性，数据还没同步完成，妥协一下，先返回旧的再说，守住最终一致性的底线即可（AP）。那要强一致性，数据没还同步完成，只能先等着，这就没办法高可用了（CP）。那我又要响应快又要强一致怎么办，不好意思，单节点吧，这样就不满足分区容忍性了（CA）。
CAP 原则对于关注技术选型时的底层逻辑还是很有参考意义的，比如 ZooKeeper，是做分布式协调的非常优秀的中间件，表面上看又快（高可用），又不怕数据丢失（分区容忍），数据又是强一致的，似乎 CAP 三条规则都满足，好处全占了。然而从底层设计来讲 ZooKeeper 遵循的是 CP 原则，当 Learder 节点挂掉时，其余 Follower 进入 Looking 状态，需要重新投票选举出新的 Learder 节点，在此选举期间，服务对外不可用。ZooKeeper 的高可用是通过精妙的设计和我们的使用规范，让这个选举时间变得很快，而从设计的底层逻辑出发是弃 A 取 C 的，所以我们使用 ZooKeeper 时，不建议在节点上存放大量数据。在使用分布式锁时，是用 Redis 还是 ZooKeeper 也应从我们的业务场景出发，判断是要 CP/AP/CA 中的哪一种，再来作出合理的选择。
咳咳，回到爱情三角理论，和朋友继续讨论择偶的话题。漂亮又事业心强的女生多半脾气比较差，因为把时间和精力投入了工作当中，留给家里的心力就会很有限。漂亮又温柔的女生可能对工作不是那么上心，需要依附于人。而温柔又上进的。。。哈哈哈。当然这是个玩笑，我还是相信有同时满足亲密、激情、承诺三个维度的完整的爱。像 ZooKeeper 一样，底层逻辑是一致性和分区容忍，而通过约定和设计，把可用性的缺陷最小化。像创业和家庭，在创业时必将大量/全部精力投身于事业当中，对家庭的关注无可避免的减少/忽视，而在财富自由的过程中又可以逐步放下事业，回归生活。在人生的不同的阶段满足不同的诉求，和同一个伴侣以不一样的形式谈多次恋爱，也许这才是完整爱情最美好的样子。
审视一下自己，爱情和事业都想要，大概只能长得着急了吧。因果倒置，逻辑鬼才。
那天和黄总说到爱情和事业我都要时，黄总皱了皱眉头，这个很难。哈哈哈也许是不愿意打击我，初生牛犊不怕虎。
嗯，其实是站着说话不腰疼。