bigbyto's repos on GitHub
Java · 35 人关注
shadowsocks-java
A implementation of shadowsocks that base on java's netty framework
Java · 11 人关注
XNineGridView
Android九宫格布局
JavaScript · 5 人关注
gitalk
Gitalk is a modern comment component based on Github Issue and Preact.
Java · 4 人关注
IndexableExpandableListView
ExpandableListView 的加强版,可以实现ios的快速索引功能,高度自定义样式
JavaScript · 1 人关注
xingty.github.io
my blog
0 人关注
ddia
《Designing Data-Intensive Application》DDIA中文翻译
JavaScript · 0 人关注
gitalk-anonmously-comment
gitalk-anonmously-comment
Java · 0 人关注
java-generic
java-generic
0 人关注
jd_scripts
CSS · 0 人关注
jekyll-TeXt-theme
💎 A customizable Jekyll theme for personal site, team site, blog, project, documentation, etc.
0 人关注
jsr
Java Specification Requests
Java · 0 人关注
socks5-server
socks5 server demo
Java · 0 人关注
spring-security-lesson
JavaScript · 0 人关注
ueditor
ueditor with aliyun oss
0 人关注
xingty
Config files for my GitHub profile.
bigbyto

bigbyto

V2EX 第 198652 号会员,加入于 2016-10-27 18:29:24 +08:00
今日活跃度排名 6203
程序员一枚,博客 ⬆️
根据 bigbyto 的设置,主题列表只有在你登录之后才可查看
二手交易 相关的信息,包括已关闭的交易,不会被隐藏
bigbyto 最近回复了
10 天前
回复了 badboy17 创建的主题 Java 又被面试官问倒了,关于分布式锁
@sujin190 实际上 mysql 数据库的插入性能并不低,只要可以绕过行锁竞争,一台 4 核 8g 的服务器承受 1 秒 6000 条插入游刃有余。加上分表设计,并发下单性能就会非常可观。
10 天前
回复了 badboy17 创建的主题 Java 又被面试官问倒了,关于分布式锁
@sujin190 我个人的观点是只有在十分严谨的场景才会考虑用锁(比如涉及到金额),对于下单的场景,使用 redis 之类的设计并发量能提升好几个数量级,这个缺点就是在极端情况下超卖和少卖选择一个。

我大概测试过 redis ,保守 6w 的原子扣减库存(lua)是很轻松的。
10 天前
回复了 badboy17 创建的主题 Java 又被面试官问倒了,关于分布式锁
@sujin190 不知道你们有没有压测的数据,这种设计在一定的节点下能承载多高的并发下单量?其实我想表达的是,如果大量请求传到了下游,就会出现多个事务竞争行锁的问题,这样系统的吞吐量就会急剧下降。
10 天前
回复了 badboy17 创建的主题 Java 又被面试官问倒了,关于分布式锁
@sujin190 再请教下你们实际场景有这样用过吗,对性能的影响有没有经过详细的测试验证。

想一下你提到的美团场景,实际上美团商家经常会有一些特价商品,如果是一些热门商家,多个用户都会选择这个特价商品再加上其他商品,如果是这种场景,这个热门商家的锁几乎是被穿透了?大量的请求都获得了锁,是否会把下游的服务击穿?
10 天前
回复了 badboy17 创建的主题 Java 又被面试官问倒了,关于分布式锁
@BBCCBB 服务在释放锁的时候就能感知到锁不属于自己了
10 天前
回复了 badboy17 创建的主题 Java 又被面试官问倒了,关于分布式锁
@sujin190

"实现正常的都是对需要操作的资源加锁而不是对服务加锁,这种情况下并不是全局锁,冲突率实际是极低的"
这一点我请教一下,你们实际锁的使用是如何设计来达到你描述的冲突低的。 实际上有很多场景我们操作资源并不是对单一资源的操作,如果对多个资源分别加锁,这就很容易出现死锁。
11 天前
回复了 badboy17 创建的主题 Java 又被面试官问倒了,关于分布式锁
不管是使用 redis 还是 zookeeper 作为分布式锁,结果必然是把所有并行请求串行化,这必然会带来一个非常严重的性能损失。如果获得锁的线程需要 10ms 完成一个任务,那么 10 个并发请求必然需要 100ms ,所以他说的“zookeeper 的能提供的并发量也有限”我表示怀疑,到底是他系统先到瓶颈,还是 zookeeper 先到瓶颈?

对于一个并行系统执行效率的评估,可以引用 csapp 中的一条公式
Ep = T1 / p*Tp

Ep: 相对效率
T1: 单线程执行时间
p: 线程数
Tp: p 个线程的执行时间

对于他的系统,解决单线程的执行效率才是最重要的,这就意味着不能串行化,要放弃使用锁。所以就需要评估他们业务系统对于锁的依赖有多重,是不是业务重要到必须不能出任何差错。

就拿扣库存这种业务场景,可以通过库存预热到 redis ,通过 redis 原子扣减库存,再通过异步任务把库存回写到数据库,达到数据的最终一致。

还有一点,redis 最致命的问题在于它不是可靠的锁,它依赖了系统时钟,在学术角度看,在某些情况下它是没法判断 2 个 event 之间的 happend-before 关系。 而 zookeeper 内部的实现的逻辑时钟,因此更加安全。
19 天前
回复了 shmilypeter 创建的主题 MacBook Pro Mac 加个内存真贵啊
开发机都要 32g 起步吧。苹果就是那么鸡贼,也没办法,上了他的贼船,只盼 intel 争气一点,让 mac 更便宜一些。
20 天前
回复了 windbadboy 创建的主题 Apple iPhone 与苹果笔记本之间不能接力了
这个功能经常间歇性抽风,原因不明。话说我的 iphone13 好像一整年没失效过,以前总老的设备容易失效。
22 天前
回复了 ZhiyuanLin 创建的主题 程序员 知乎喜迎全平台隐写水印
@ZhiyuanLin 这个真的是很危险,如果自己的 id 被泄漏出去,别人可以拿来替换然后截图,达到嫁祸的目的。就算没做过都是有口难辩。
关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2920 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 20ms · UTC 13:01 · PVG 21:01 · LAX 06:01 · JFK 09:01
Developed with CodeLauncher
♥ Do have faith in what you're doing.