quericy

quericy

以白羽为衣,于天际起舞。
V2EX 第 71148 号会员,加入于 2014-08-17 16:37:55 +08:00
今日活跃度排名 2527
根据 quericy 的设置,主题列表只有在你登录之后才可查看
quericy 最近回复了
战略性 Mark,就差个房了
4 天前
回复了 uTools 创建的主题 分享创造 两年过去了,那个叫 uTools 的怎么样了
@wgbx #105 如何设置的双击 ctrl 使用? Mac 上没看到设置键盘按键呼出超级面版的选项。

试着全局关键字热键里添加"超级面版",打开的是设置菜单页
试试 Instrument ?可以运行时做字节码增强

https://tech.meituan.com/2019/09/05/java-bytecode-enhancement.html#3-2-instrument
抽奖:[213]
评论区一路看下来,楼主的"薄雾"和 Snowflake 本质上还是在 CP 和 AP 间抉择的问题。

Snowflake 通过时间戳的递增特性实现了不引入单点达到 AP,代价是获取时间戳的性能开销和承担时间回拨的风险;
"薄雾"通过引入 Redis 来确保"中位"号段全局递增,规避毫秒级时间的冲突和获取开销,代价是引入了新的单点;

引发质疑的原因除了标题以外,还有 Jmeter 仅仅 5000w 的唯一性测试在缺乏数学论证依据的前提下也说服不了评论区的各位。

个人感觉更关键在于,楼主的这套方案在分布式系统实际部署中将更加缺乏说服力:
1,性能瓶颈。举个简单的例子,异地双机房部署的场景下,"薄雾"引入的 redis 单点如何确保对端机房服务的性能表现? Snowflake 只需要做到机器时间对齐,"薄雾"跨机房的网络开销和抖动均会大大拖慢发号性能,网络 IO 的损耗可不是和时间戳获取可不是一个量级的。

2,可用性。redis 所在机房断网时,异地机房是否还可对外提供服务? Snowflake 的 AP 特性可以在确保时间正确的前提下提供服务,"薄雾"目前的方案依赖 CP 在上述场景下是无法满足可用性的。
自己算法的抽奖??
163 天前
回复了 YUX 创建的主题 问与答 有什么给 mbp 降温的好办法么
装个 iStat Menus,风扇转速拉满
这个是绕过 iOS 限制了?还是用录屏实现的
203 天前
回复了 billion 创建的主题 奇思妙想 写一句话在这里,下一个 2 月 29 号来看
感谢提醒,回想了一下 4 年前回复这个帖子的场景

现实永远和预想不同,现实总是出乎意料之外
234 天前
回复了 Eagleyes 创建的主题 macOS mac OS 输入法哪家强? 10.15.3
鼠须管要慢慢养词库的
关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1073 人在线   最高记录 5168   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 14ms · UTC 22:31 · PVG 06:31 · LAX 15:31 · JFK 18:31
♥ Do have faith in what you're doing.