第一你已经经济独立了，请你努力让自己的人格独立，并学会如何拒绝道德绑架。
第二你要学会独立，为自己的每个决定独立思考并在做决策后承担所有后果。
第三要始终牢记，不要为别人的决策负责。尊重他人命运，不要圣母心发作，牺牲自己去补充别人的错误。

所谓独立是指，你能够笃定自己可以为自己的每一个决定负责到底，无论这个决定造成什么后果你都能够承担下来。
你若无法拒绝家里一哭二闹三上吊的道德绑架，你永远也不可能得到幸福，因为你会一直被迫为别人的决策买单，永远无法享受真正属于自己的时刻。

重点不是是否买房。
需要考虑的是如何平衡意外的风险和个人的便利。
缺少廉价且稳定的出租房的地方，买房的人就会多一些。比如广州，就有很多城中村降低购买群体的意愿。

而有很多城市的制度，其实是在有意控制城市的年龄结构，有针对性的淘汰这个城市不需要的人口群体，比如低收入群体，比如劳动产出下降的高龄劳动人口。引导劳动人口买房恰恰是这些制度中最有效的措施之一，和制度对抗是需要付出很多额外的成本的。
如果没有足够的能力留下来，又不愿意离开，必然要舍弃一些个人诉求的。

要相信社区的真实需求，尊重开源项目的正常生命周期，接受开源本质上是一种用来表达个人的主观劳动意愿的无偿劳动产出。因此一个开源项目是否有人维护，除了有赞助之外，最重要的其实是是否有人对它要解决的问题感兴趣。
底层如 openssl ，log4j 都会因为捐赠太少导致研发不足漏洞修复不及时捅出大篓子，如果对解决这个问题感兴趣的人不多，又没有足够的捐赠购买开发人员的时间进行维护，就说明这个开源项目的生命周期走到了尽头了，因为即没有开发者对它感兴趣，又没有用户愿意为之付费。

正因为维护一个问题的解决方案是如此的艰苦，所以大家才会如此尊敬那些愿意数十年如一日维护某个问题领域的解决方案的人，正是他们出于个人兴趣的劳动产出，才让后来者在面对相同问题时不至于束手无策。

请考虑以下场景
1. 订单出问题了，客户通过电话能不能正确报出订单号进行处理
2. 订单传递的时候有没有数值转换导致精度丢失的情况
3. 只看订单号，不额外查询任何数据，能从订单号中获得什么信息，哪些信息是用户关心的，哪些是客服关心的，哪些是研发人员关心的
4. 订单的生成的真实 qps 诉求是多少，通过什么方式可以在保证一致性的前提下增加生成的 qps

启用 vm.overcommit_memory=1 ，系统将会在 OOM kill 时保留一份 core dump
触发后去查对应目录中拿当时的 core dump 文件 *.core 。跑 gdb 分析

1. 结婚是找和你一同应对人生后续挑战的战友，重点是对要应对的挑战要达成一致，无法达成一致建议分手
2. 战友之间需要花费时间磨合，要多发掘战友的优势，主动承担责任，同时也要信赖战友的能力，包容缺点。因为战友之间的信赖程度是需要有针对性的练习磨合才能增强的。
3. 要享受两个人共同解决困难的过程，重点是解决困难，推诿责任对解决问题没有任何帮助
4. 除非要复盘争夺决策权，否则没必要在问题是谁造成的上争吵

实操上，这几个经历我觉得对评估磨合程度的有很大的帮助
1. 共同学习的过程，学一门新技能，或者共同收集整理信息等需要协作的事情
2. 遇到预期外的问题如何应对，比如长途旅行发生行程变更，缺少证件，赶不上飞机火车之类的，尤其特别疲劳的情况下，情绪濒临失控的情况下还能不能做出合理的决策
3. 对热点问题的讨论，看双方的关注点以及给出的结论
4. 分歧、争吵的解决方式，是否能就事论事

信赖程度的损伤本质上是不信任战友的能力，这个是很难修复的，如果不能包容或者改进，一定要明确指出来。

人情是一个很矛盾的纽带，当它兑换成利益的时候，给予的人永远觉得给多了，获得的人又会觉得给少了，它永远不会得到一个双方认可的价值评估，对于负债方的视角中，长期来看会被通货膨胀稀释

缺少法律约束，没有强制力量保障的约定是最脆弱的，违约收益远大于履约。人的道德底线会因为自身掌握的资源匮乏不断下降，你不能要求一个从底层爬上来的人保持良好的道德基准，你也很难假定一个身陷囹圄的人翻身之后还能遵守约定

宗族的投资，是有宗族的强制力量保障的，因为宗族的强制力量在很多地方被法律取缔了，现在大家族的人情纽带已经很弱了。
义务教育、助学贷款、农业补贴这些属于国家有能力通过未来的税收及其它强制力量收回的补贴，不属于这个范畴。

建议不要照着 5 年的使用寿命买，也不要照着以后预留升级的想法去升级配置。
生产力工具抱着这样的想法容易陷入 DIY 的误区，一次拉满，5 年内都够用了，实际上不管你怎么拉满，等到第三年新配件能带来的提升都会让你按捺不住换新的想法。

建议按三年的使用寿命，按照三年后出二手的心态去 DIY 。因为这几年 DIY 的配件升级还有一些空间，大概率是买了这代，下代换新的动力不会太高，因为新配件的提升不会太大，但是隔两代的配件会有比较明显的提升。

性能上，按需购买，你是买生产工具，但大部分 DIY 配件分享都是基于游戏去配的，导致显卡的预算在 50% 这样，生产力需要去找和你生产力场景相识的文章或者视频做为参考，因为升级配件完全可以靠出二手回血，实在不确认，可以对比一下新配件和上一代同级别二手的差价，算一个使用折旧率。


生产力绝对是内存越大越好，因为大部分软件都是常驻内存的效率高，内存日常占满，所以内存上多花钱收益最大，CPU 和显卡看使用场景，满载的时间其实占比并不会太大。

折旧费上，我建议按每年折旧费来算总预算，比如一年 3000 的折旧费，那总预算就 9000 ，如果能接受的折旧费用高，就把预算拉高一些，接受不了，不如控制自己加钱的妄念，换成先用它赚钱，三年之后再换新的这种想法去配。


我可以举个例子，我不做图像开发，也没有剪辑需求，所以也没有显卡的需求，三年前我配的是 3700x + 32G ，大致 5300 。
现在这套配件工作上还够用，但是新的 CPU 的提升已经让我计划换新了。而我要出掉的是主板+CPU+内存，我能接受 1200 出掉这些，对比原价 3400 ，折旧费大概是 2200 ，就是每年不到 1000 的折旧费。

HR 的任务是用最小的成本挑出合适的候选人
尽早回复消息属于照顾候选人情绪，这不属于 HR 的高优任务

付费的公司想要的是，如何尽快筛出合适的候选人，这包括，如何搜出合适的候选人，如何验证候选人的简历上的技能与项目经历符合岗位需求。

所以看起来，招聘平台帮助候选人提供更多有公信力的能力证明，减少双方在匹配度的沟通成本才是收益更大的事情。

我觉得会有一定受众。
现在招聘市场是一个双向开盲盒的过程，候选人不知道岗位侧重考察的能力，公司不知道候选人的技能值都点在了什么上。

而一个人长时间的职场经历，能力成长也是有价值的。
面试官大可以通过兼职来引入资历得到认可的面试官，只要公司能够认可面试官的评估结果，为此付费，也算是能够减少面试筛选成本的一种企业服务。

同样如果能够培养候选人每年进行一次面试的习惯，逐渐积累个人技能的评估结果，会对候选人的能力评估有更全面的数据做支撑，更有利于给企业做人才筛选和推荐服务。
后续还可以根据市场需求持续对接其它技能培训的机构给候选人扩展相关领域的技能学习获得收益。

这种辅助面试的服务有很不少技术达人都在利用自己的人脉做，说明还是有市场需求的，只是市场需求是否能够养得起一家公司，还需要实际运营平台才能得到市场反馈。

重点是看作者如何论述自己推导结论的依据，推导结论的过程更重要。
比如这本书的几个中心论点，生产力决定了什么，自然环境决定了什么，它们的作用对社会体系产生了什么影响，理解这些比知道结论更重要。

骑手如此不顾安全的原因是，为了赚够维持基本生活的钱，必须分秒必争，甚至不惜违反交通规则。
真正的原因是平台作恶而又不建立完善的监管机制，骑手是被压迫的那一方。外卖平台为了争夺用户，通过各种手段压榨商家及骑手来实现让利给消费者，这就必然导致被压榨的商家及骑手为了赚取足够的利益不惜违反各种法律法规。
平台真正要做的应该是提供更好的监管方案，避免骑手犯错，比如同样的线路，就应该有一个最低配送时间，一旦低于这个配送时间，说明骑手可能违规了（超速、逆行等），只要平台不是选择性执法，确实做好处罚违规的，奖励遵守规则的，将整体生态才可能变好。

否则就会持续卷，就和大货车超载超速一样，确实指定了非常多的检查、处罚方式，但因为无法及时处罚违规的人，让那些违规的人大概率能获得更多的利益，就会让市场陷入恶性竞争。大车超载的情况是如何逐步缓解的？是天眼系统，是越来越多的摄像头及检查点，让违法的成本高于收益了，违法的案例才会减少，而那些违法成本不够高的地方，依然存在大量违法案例。

@hyacinthus

这是资源划分的问题，分租户天然就应该可以支持分布式部署才对，无论按 database 、table 、field 做为多租户的标识，都应该要支持在入口分流到不同的实例上，按租户将负载平摊到不同的物理资源上。
实现上，只要保证一个事务的修改，能够在一个集群内执行完即可，至于不同租户是否要在一个实例内，按需拆分。

@Chad0000

如果没有多实例的需求，比如不同租户的资源需求不一样，一个连接，通过 database name 区分，复用底层数据库的连接是比较理想的。

多版本主要是为了平滑升级吧，因为多租户的迁移本身是一个较长周期的过程，最好是能按租户升级。

https://www.v2ex.com/t/850237#r_11620231
https://www.v2ex.com/t/850237#r_11622092

纵上，如果不考虑历史包袱，我认为多租户系统需要考虑这几个问题。
1. 商户之间的资源可以隔离
2. 部署版本的影响范围可控，可自动化
3. 能复用上基本的数据库特性，如索引
4. 最好支持私有化部署
5. 跨租户的业务集成方案

所以数据库层面：
按租户分 database
一个租户的数据，尽可能落在一个 database 中，而不是随着不同的微服务分散在不同服务的 database 上。

服务部署
按版本部署，力求业务代码仅提供计算能力，一个租户可以自由地在兼容的两个版本中来回切换

请求路由
按租户的 tenantId 区分，力求能够根据每一个 tenantId 提供一个路由表声明，实现不同 tenantId 转发到不同的基础设施上。如 tenantId.mysql.local.svc 指向不同的 mysql 实例

开发约定上
按分布式系统来考虑实现方案，如 id 不能用自增，而是生成线性有序的唯一 id ，业务不能假定都能在一个事务中提交，而是可以分阶段，支持幂等等
禁止破坏性的变更，至少应该让两个版本之间可平滑过渡，为对应的功能增加合适的开关，这个开关也属于租户的业务数据，落到租户的 database 中。

至此 CI/CD 才能实现随时上线，按需开启。

@Chad0000
跨库的业务操作应该显式写集成业务，这种集成业务是隐藏不掉的，应该让这类的业务归纳入版本管理中，至于跨租户的数据集成问题，可以考虑引入其它 OLTP 数据库来支持集成。

升级的问题同理，变更是很难通过自适应的业务流程计算出 diff 并升级的，应该让开发讲升级 /降级的变更写成迁移脚本，归纳入版本管理中随代码迭代。
升级无法进行版本管理并自动化，会让新业务的上线变得更加困难，需要支持按租户区分功能开关的形式，业务代码可以随时灰度上线。隔离好变更的影响范围。

多租户就应该强隔离，每个租户一个 database ，让业务数据有明确的类型定义，有利于复用数据库的各种特性，租户之间的业务差异性也更容易划分清楚。

缺一个 BFF 框架，展示数据不能受限于后端开发人员的约束。
https://maguangguang.xyz/backend-for-frontend
https://maguangguang.xyz/bff-governance

看看之前 v 站用户的分享