byehair

1 、内存队列（或者 MQ ），排队对单券扣减，减少无畏的 CPU 消耗、加解锁消耗
2 、使用 Redis 的 decrby 进行扣减，通过内存扣减提升性能
3 、如果是多次的金额相同，还可以使用券预置拆分策略，减少锁竞争

很棒的作品。
1. 页面设计感很强，比 bento 和 linktree 的细节更好，包括组件的边框颜色和 shadow
2. 国内访问比较流畅，不像 bento 和 linktree 很多时候链接图标都无法加载

小建议：
1. 过于居中，可以往左右更分开一点
2. 操作逻辑可以优化，现在点击底部按钮，会在最上面增加新组件，将原有存在的组件挤压到下面，这比较难受
3. 现在无法更改邮箱、无法更改链接地址(用户名)、还有现在少于 3 个字符无法注册成功但是提示不明确
4. 添加链接类型偶尔会失败，表现就是，增加后是一片空白
6. 除了微信和小红书，还可以多增加一些比如 github 、抖音、之类的
7. 我看目前类似的产品都不支持自定义域名，其实一直需要这个功能

另外，国内还有位大佬的产品也不错，kee.so ，功能和操作上都不错，就是界面没有 biofy.cn 好，哈哈

我的： https://biofy.cn/han

https://chuanliu.org （高质量博客订阅）

---

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

川流，完全摒弃数量概念，只有三个标准，内容高质量、博主文笔好、博客美观。
经历了欣喜、小火、停站、重新拾起、不再关注外界的过程，去掉了自主提交、统计、排序、排名、访问统计、连操作后台都去掉了，偶尔看到好的质量高的博客，纯手工操作放上去，哪怕是我创办的，我自己文章质量也没有资格进入。

比较好的博客聚合收集站↓：

川流： 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

---

是你接触的少了，这方面的信息就减少流向你了，你对这方面的感知就会变淡，独立博客一般都是死一批，活一批，再死一批，再活一批。

当你要访问共享资源，又可能会发生并发修改问题的时候，没办法不用锁。如果不会造成并发修改冲突，无锁编程肯定性能高。

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

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

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

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

1. 你的业务场景确实暂时不需要，不必强加
2. 你还没有在线上遇到过由并发读写产生的 bug ，所以还没发现
3. 因为缺少并发处理经验，所以暂时缺少这部分的意识，需要补充

@hekkowoerld 并没有实际对比过，没有实际对比主要是两点原因：
1. 懒
2. 乐观锁和悲观锁的性能差异在不同条件下是不一样的，要看自旋的成本和调度的成本

假设你获取到锁的线程执行任务周期长，或者锁竞争很激烈，那么也许悲观锁性能更高
反之亦然

我的实际工作中，只要可能存在并发冲突的时候，在数据库层面我几乎都会使用乐观锁处理，但几乎很少使用悲观锁。
但是，但是，但是，
在数据库操作之前，我一般会使用其他手段，前置处理并发，比如使用 redis 做分布式锁、比如使用消息队列消费再写数据库等。

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

一个不恰当的例子：
宇宙飞船是密封的，但是更保险的是穿上宇航服，因为有可能宇宙飞船被撞出一个洞，也可能宇航员要出仓执行任务，虽然有各种外层防御措施，但宇航服是最后一道防线。

一些浅见：
技术方案上大部分时候是没有绝对答案的。
楼主所提出的是否要未 kafka 兜底的问题，其实要看前置条件，就像代码在机器上执行也需要上下文一样。

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

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

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

兜底：
一切安好。

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

---

另外，其实楼主的问题中反复提到，是为了 kafa 兜底，那其实更应该考虑的是，如何提高和保障 kafka 集群的可用性，而非采集服务。