这种都是 HTTPDNS 和长连

赞，蹲一个 Figma 版本

这个场景在现在这个年代更适合用 flink 聚合成维表，目标数据源可以是 Doris/Druid 这类 OLAP 组件

@JasonLaw 如果你是 DBA 但不理解这两个点那请多与研发沟通；如果你是研发但不理解这两点那说明还需要多积累开发经验和架构设计经验；如果你是其他角色但不理解这两点那可以通过阅读各类架构设计资料来补全认知

@JasonLaw 外键约束都不是由人保证的，逻辑外键、物理外键均是如此

数这么设计虽然很多人会说索引性能有问题，但其实大部分场景都遇不到所以还好，真正问题比较大的是你们用的这个 uuid 生成方案是不是可靠。

另外数据库字段一般都是推荐用下划线分割，主要是为了避免忽略大小写等暗坑，当然这个还是要看你们的编码规范是怎么定的。

三连支持，视频剪得很棒（尤其是开头那部分），如果能加个章节就更好啦

没想到 2021 年还有很多人在争论是否该使用关系型数据库的外键，这种外键我们更习惯称其为物理外键，与之相对的是由业务逻辑控制的逻辑外键，实际上当今稍稍复杂些的业务都在使用外键，只是使用的是逻辑外键而非物理外键。

物理外键是我们学习数据库原理和设计时都会遇到的章节，它的主要优势是可以通过数据库实现强制的 Referential Integrity，即引用完整性。但这样的完整性使用逻辑外键也完全能实现，有人认为逻辑外键由于完全依赖业务代码所以无法真正保证完整性，但这其实是个伪命题，因为物理外键也是由「人」来设置的，你只能保证设置过的物理外键能保证引用完整性，至于那些没考虑到的、设计错误的数据关联关系仍然是物理外键无法解决的，在这一点上物理外键和逻辑外键是没有实质区别的。而实际上当今的云原生架构在数据层面追求的是分布式和最终一致性，单个 DB 存储所有数据的时代早已过去，数据在服务间流转已经是常态，此外国内场景下很多数据也不被允许直接物理删除，物理外键的作用在现代架构下变得微乎其微。物理外键不是银弹，它甚至都没有成为银弹的实力。

而说到劣势，物理外键在现代后端架构中的缺点已经越发明显。分场景分析如下：

- 对于传统企业应用，交付后几乎没有大面积迭代，使用物理外键是无可厚非的，这也是对传统软件开发模式和架构的传承。但现在有越来越多的企业选择使用 SaaS 或自主进行研发和维护，这也就意味着产品的迭代会比此前频繁得多，进而变为下文提到的流量小但迭代频繁的项目。
- 玩具型项目用不用外键都没有区别。
- 大流量项目使用物理外键无疑是在埋坑，抛开颇受争议的性能问题不谈，物理外键无法满足分库分表、单元化等现代架构设计的需要，甚至在这些架构下还会成为累赘要额外花费时间改造掉。
- 小流量项目的迭代速度可不慢，领域模型很难稳定下来，而使用了物理外键也就意味着系统是基于数据库进行的建模，那么当前的物理外键设计迟早有一天要面临变更，这所带来的维护成本（改表困难、业务拆分和聚合困难等）是巨大的，这也是为什么现在很少有人使用存储过程的原因。

可见物理外键在数据模型迭代频繁以及大流量场景下具有非常明显的劣势。

其次是职责问题，在人员职责上，DBA 与业务强耦合本身就是不合理的，这和为什么要做前后端分离是一个道理，这也是为什么当今很多互联网公司会选择一名 DBA 对接一个后端大组甚至事业部的原因，DBA 的职责已经下沉到更核心的数据库稳定性和性能提升上。而在架构中的分层职责上，在持久层耦合业务逻辑是非常不明智的，因为这意味着你的架构会严重依赖某个数据库选型甚至某个特定版本数据库的功能，领域模型与数据模型的耦合也会产生很多人噩梦中的一个 Service 层走天下的情况，业务逻辑很难做进一步的抽象和拆分，至于读写模型分离、CQRS 也就是更不可能的事情了。

综上，使用物理外键能带来收益非常有限，但隐性成本（只要业务还在发展，那未来早晚会变为显性成本）却非常高，其本身又可以被逻辑外键所替代，那除了个人或团队喜好，我实在找不到继续使用物理外键的理由。

这些需求买个 1k 多的 4125 工控机就能满足，便宜好用还省电

可行而且很简单，参考官方文档 https://support.apple.com/en-us/HT208891

巧了不是，我第一笔学费就是交给 OGO 的，分享下我的经历： https://easonyang.com/2021/08/06/investment-speculation-gambling/

山泽的那款 Type-C 转 DP 亲测可以 4K@60hz

这个比较玄学，我也遇到过，试试完全重新匹配下试试

最后一条有个 typo，应该是 「在文章列表中使用 h2 标签替换 h1 标签以符合 Bing 等平台的 SEO 要求」

@ihipop 已支持 Server 酱和 Qmsg 酱，可以部署在国内给微信和 QQ 发通知啦～

主流方案就是二楼所说的这些搭配使用，整合的成套实现可以参考 cat https://github.com/dianping/cat 。总的来说想做好监控不仅仅需要一个好的监控服务端实现，客户端基础组件层面的埋点上报相关工作也是重要且繁多的

非 C 端用自增就行了，C 端建议新项目伊始就用 Snowflake，不然后面体量大了想改就不容易了。UUID 方案如楼上所说没有任何优势所以就不要考虑了。

至于如何实现可靠的分布式 Snowflake 有很多轮子，推荐这款： https://github.com/Meituan-Dianping/Leaf

实际使用中单例场景很难复现不加 volatile 导致的指令重排问题。但由于总是有概率发生的，所以还是需要加上的

druid 还是很稳定的，在复杂场景下，关闭了 removeAbandoned 功能的 druid 其实和 HikariCP 的性能差距并不是很大。

要说问题的话，一是这个项目前景不明，二是串行建连导致的线程 block 有点迷