helloluckydamon 最近的时间轴更新
helloluckydamon

helloluckydamon

V2EX 第 692597 号会员,加入于 2024-05-24 15:47:32 +08:00
helloluckydamon 最近回复了
https://chuanliu.org (高质量博客订阅)

---

https://tech.chuanliu.org (技术博客订阅)
https://forumhub.chuanliu.org (主机论坛订阅)

川流,完全摒弃数量概念,只有三个标准,内容高质量、博主文笔好、博客美观。
经历了欣喜、小火、停站、重新拾起、不再关注外界的过程,去掉了自主提交、统计、排序、排名、访问统计、连操作后台都去掉了,偶尔看到好的质量高的博客,纯手工操作放上去,哪怕是我创办的,我自己文章质量也没有资格进入。
52 天前
回复了 liugezhou 创建的主题 分享发现 这两年大家还有在坚持写博客吗?
比较好的博客聚合收集站↓:

川流: https://chuanliu.org
BlogFinder: https://bf.zzxworld.com
个站商店: https://storeweb.cn
博友圈: https://www.boyouquan.com
中文独立博客列表: https://github.com/timqian/chinese-independent-blogs
FindBlog-Telegram 频道: https://t.me/FindBlog

---

我的博客: https://go.seeyou.me/fxpm7

---

是你接触的少了,这方面的信息就减少流向你了,你对这方面的感知就会变淡,独立博客一般都是死一批,活一批,再死一批,再活一批。
52 天前
回复了 javaisthebest 创建的主题 程序员 咨询一个关于锁的业务问题
当你要访问共享资源,又可能会发生并发修改问题的时候,没办法不用锁。如果不会造成并发修改冲突,无锁编程肯定性能高。

比如使用旁路缓存模式,从数据库加载 1 万条数据列表大概 10MB 到 redis ,这时候并发请求读取,A 线程读取数据库 1 万条,B 线程也来读取发现 Redis 数据不存在也去请求数据库,这时候 B 读取数据库发现有人更新了读取到了 1 万零 1 条,然后 B 线程执行快先完成将数据写入 Redis ,A 线程此时慢了一步继续写入 Redis ,那最新的一条数据就被覆盖了,这时候缓存和数据库就不一致。

当然也可以用队列来处理这种情形。

信号量一般用在对资源的数量要求极度精准的情况,比如限流最高就要求同一单位时间 1000 人访问,那使用信号量就会特别精准,而且还能应对流量突刺,同时不会产生临界区问题,你使用其他的限流算法就比较难做到。

所以,如果你现在还没有使用锁和信号量,那一般是以下三个情况:

1. 你的业务场景确实暂时不需要,不必强加
2. 你还没有在线上遇到过由并发读写产生的 bug ,所以还没发现
3. 因为缺少并发处理经验,所以暂时缺少这部分的意识,需要补充
57 天前
回复了 ljzxloaf 创建的主题 程序员 你们会用乐观锁来防止并发冲突吗
@hekkowoerld 并没有实际对比过,没有实际对比主要是两点原因:
1. 懒
2. 乐观锁和悲观锁的性能差异在不同条件下是不一样的,要看自旋的成本和调度的成本

假设你获取到锁的线程执行任务周期长,或者锁竞争很激烈,那么也许悲观锁性能更高
反之亦然
61 天前
回复了 ljzxloaf 创建的主题 程序员 你们会用乐观锁来防止并发冲突吗
我的实际工作中,只要可能存在并发冲突的时候,在数据库层面我几乎都会使用乐观锁处理,但几乎很少使用悲观锁。
但是,但是,但是,
在数据库操作之前,我一般会使用其他手段,前置处理并发,比如使用 redis 做分布式锁、比如使用消息队列消费再写数据库等。

数据库层面使用乐观所或者悲观锁是我的最后一道防线,前置的分布式、内存锁、队列等都是为了从宏观上更高效的防止并发冲突。

一个不恰当的例子:
宇宙飞船是密封的,但是更保险的是穿上宇航服,因为有可能宇宙飞船被撞出一个洞,也可能宇航员要出仓执行任务,虽然有各种外层防御措施,但宇航服是最后一道防线。
一些浅见:
技术方案上大部分时候是没有绝对答案的。
楼主所提出的是否要未 kafka 兜底的问题,其实要看前置条件,就像代码在机器上执行也需要上下文一样。

哪些场景需要楼主进行兜底:
* 指标与责任:日志服务的可用性、数据的完整性指标是由楼主团队来负责的
* 业务与价值:日志采集是 P0 级服务,数据价值高,不能丢失
* 能力与现状:发送方目前无能力进行异常兜底,如重试、暂存、监控告警等

哪些场景不需要楼主进行兜底:
* 发送方已经做了重试、暂存、落地等异常处理进行兜底,同时数据短暂丢失可以接受

兜底的理由有很多,数据价值、服务可用性等等,不兜底的理由只有一个,就是相比之下,有更有价值和急切的事情要做。

兜底:
一切安好。

不兜底:
未来某一天日志丢失、不可用,两个团队互相指责、推卸、谩骂、诋毁、内耗。

---

另外,其实楼主的问题中反复提到,是为了 kafa 兜底,那其实更应该考虑的是,如何提高和保障 kafka 集群的可用性,而非采集服务。
如果你要使用阿里云,必须要在阿里云买服务码或者服务器进行接入备案(接入备案几乎等同于重新备案),并且,如果你想保持阿里和腾讯的备案都不掉,你的域名要保持一个子域名解析到腾讯服务器(目前可以使用 cos 进行替代,但未来可能会不行),腾讯现在巡查很厉害,如果发现在腾讯没有服务器解析,会给你下发 48 小时整改,如果未整改,会取消接入备案,如果此时你只在腾讯备案了,那么你的主体备案直接会被注销,你的备案就废了。
68 天前
回复了 seekseat 创建的主题 编程 并发编程和异步编程的区别
@Building 麦辣鸡翅哈哈哈哈哈哈哈哈😂有趣
恭喜恭喜~
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   940 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 12ms · UTC 19:48 · PVG 03:48 · LAX 12:48 · JFK 15:48
Developed with CodeLauncher
♥ Do have faith in what you're doing.