byehair 最近的时间轴更新
byehair

byehair

V2EX 第 692597 号会员,加入于 2024-05-24 15:47:32 +08:00
byehair 最近回复了
很棒的作品。
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 (主机论坛订阅)

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

---

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

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

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

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

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

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

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

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

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

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

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

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

兜底:
一切安好。

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

---

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