V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  mreasonyang  ›  全部回复第 1 页 / 共 11 页
回复总数  210
1  2  3  4  5  6  7  8  9  10 ... 11  
这种都是 HTTPDNS 和长连
2022-06-03 08:52:06 +08:00
回复了 Zilize 创建的主题 分享创造 基于 Draw.io 画了个好看的单页双栏简历模板
赞,蹲一个 Figma 版本
2021-12-31 13:29:42 +08:00
回复了 Gaussen 创建的主题 Redis 关于 redis bitmap 的疑问
这个场景在现在这个年代更适合用 flink 聚合成维表,目标数据源可以是 Doris/Druid 这类 OLAP 组件
@JasonLaw 如果你是 DBA 但不理解这两个点那请多与研发沟通;如果你是研发但不理解这两点那说明还需要多积累开发经验和架构设计经验;如果你是其他角色但不理解这两点那可以通过阅读各类架构设计资料来补全认知
@JasonLaw 外键约束都不是由人保证的,逻辑外键、物理外键均是如此
2021-09-05 17:32:58 +08:00
回复了 Geekerstar 创建的主题 MySQL MySQL 数据库主键用了字符串的 UUID 怎么办?
数这么设计虽然很多人会说索引性能有问题,但其实大部分场景都遇不到所以还好,真正问题比较大的是你们用的这个 uuid 生成方案是不是可靠。

另外数据库字段一般都是推荐用下划线分割,主要是为了避免忽略大小写等暗坑,当然这个还是要看你们的编码规范是怎么定的。
2021-09-05 17:26:54 +08:00
回复了 sangbill 创建的主题 Flutter Flutter 20 分钟打造 Apple Watch 个性陈列流
三连支持,视频剪得很棒(尤其是开头那部分),如果能加个章节就更好啦
没想到 2021 年还有很多人在争论是否该使用关系型数据库的外键,这种外键我们更习惯称其为物理外键,与之相对的是由业务逻辑控制的逻辑外键,实际上当今稍稍复杂些的业务都在使用外键,只是使用的是逻辑外键而非物理外键。

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

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

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

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

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

综上,使用物理外键能带来收益非常有限,但隐性成本(只要业务还在发展,那未来早晚会变为显性成本)却非常高,其本身又可以被逻辑外键所替代,那除了个人或团队喜好,我实在找不到继续使用物理外键的理由。
2021-08-21 12:26:02 +08:00
回复了 julypanda 创建的主题 硬件 彦祖们, 2021 了, 客厅电脑的选择有推荐吗?
这些需求买个 1k 多的 4125 工控机就能满足,便宜好用还省电
2021-08-18 18:17:59 +08:00
回复了 djyde 创建的主题 Apple 如何在 MacBook 安装两个独立的 macOS?
可行而且很简单,参考官方文档 https://support.apple.com/en-us/HT208891
2021-08-06 02:49:18 +08:00
回复了 xx19941215 创建的主题 随想 我是如何在币圈亏钱的?
巧了不是,我第一笔学费就是交给 OGO 的,分享下我的经历: https://easonyang.com/2021/08/06/investment-speculation-gambling/
2021-08-02 10:13:07 +08:00
回复了 Cassano 创建的主题 Apple 小米的 USBC 转 HDMI 可否用在 MBP16 的机器上?
山泽的那款 Type-C 转 DP 亲测可以 4K@60hz
2021-08-02 10:10:59 +08:00
回复了 Awes0me 创建的主题 Apple AirPods Pro 只要连过电脑,右耳就充不进电
这个比较玄学,我也遇到过,试试完全重新匹配下试试
2021-08-01 22:48:23 +08:00
回复了 mreasonyang 创建的主题 分享创造 hexo-theme-even 的简易增强版
最后一条有个 typo,应该是 「在文章列表中使用 h2 标签替换 h1 标签以符合 Bing 等平台的 SEO 要求」
2021-08-01 14:31:20 +08:00
回复了 mreasonyang 创建的主题 分享创造 新玩具:基于腾讯云 SCF 的 HTTP 探活函数
@ihipop 已支持 Server 酱和 Qmsg 酱,可以部署在国内给微信和 QQ 发通知啦~
2021-08-01 03:12:43 +08:00
回复了 Sparkli 创建的主题 程序员 聊聊互联网公司监控技术栈选型
主流方案就是二楼所说的这些搭配使用,整合的成套实现可以参考 cat https://github.com/dianping/cat 。总的来说想做好监控不仅仅需要一个好的监控服务端实现,客户端基础组件层面的埋点上报相关工作也是重要且繁多的
非 C 端用自增就行了,C 端建议新项目伊始就用 Snowflake,不然后面体量大了想改就不容易了。UUID 方案如楼上所说没有任何优势所以就不要考虑了。

至于如何实现可靠的分布式 Snowflake 有很多轮子,推荐这款: https://github.com/Meituan-Dianping/Leaf
2021-07-31 14:23:05 +08:00
回复了 acr0ss 创建的主题 Java 求构建: Java 单例 double-check volatile 关键字的反例。
实际使用中单例场景很难复现不加 volatile 导致的指令重排问题。但由于总是有概率发生的,所以还是需要加上的
2021-07-31 14:17:38 +08:00
回复了 bthulu 创建的主题 程序员 阿里的 druid 怎么样, 包是不是有点太大了
druid 还是很稳定的,在复杂场景下,关闭了 removeAbandoned 功能的 druid 其实和 HikariCP 的性能差距并不是很大。

要说问题的话,一是这个项目前景不明,二是串行建连导致的线程 block 有点迷
2021-07-31 13:59:03 +08:00
回复了 pigbug 创建的主题 程序员 从程序员的角度看灰度发布,是不是真的很难实现和落地?
看重灰度准效率的业务一般都很难在数据层面通过两套逻辑的异步同步来实现灰度的,搞不好就会由于一致性问题导致真正的大事故。如果能做到蓝绿发布,并且底层数据实现了单元化存储,那应该还是能解决一部分问题的。

百分比灰度是很基础的思路,但楼主说的小比例时反馈滞后直到大比例才收到反馈这种情况在中小流量的业务中确实很容易遇到。

我理解这个问题难以彻底解决,但可以通过类似 AB 测试的方式圈定人群逐步放量,从而实现更精细的灰度控制。

例如对于面向 C 端的业务,在上线时以相关的研发和测试为基础灰度点,逐步向外扩大,从而做到影响范围尽量小且反馈效率更高。
1  2  3  4  5  6  7  8  9  10 ... 11  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2754 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 35ms · UTC 15:06 · PVG 23:06 · LAX 08:06 · JFK 11:06
Developed with CodeLauncher
♥ Do have faith in what you're doing.