V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  luoqeng  ›  全部回复第 1 页 / 共 20 页
回复总数  400
1  2  3  4  5  6  7  8  9  10 ... 20  
38 天前
回复了 voidispiral 创建的主题 程序员 为什么 nats 这个消息队列用的这么少
游戏服务的特殊性,只是把这个当成通信的 BUS 而已,取代了服务发现,消息量不大情况下还可以。
订阅主题就可以实现 RPC 和其他服务通信,很方便,少了服务发现,服务之间建立连接。
at any snapshot in time no two clients think they hold the same lock is based on the following assumptions: bounded network delay, bounded process pauses and bounded clock error.
[client 自己需要主动去检查 lock 的有效性] 这是一个异步操作,发生请求检查锁有效,到接收到锁有效返回,这个是有网络延迟的,你接收的锁有效的消息可能是过期的,锁已经超时释放掉了。
你给的那个 stackoverflow 下面还贴了一个 GC 暂停的案例 https://cwiki.apache.org/confluence/display/CURATOR/TN10
解决不了,记得好像已经证明了没有安全的分布式锁。
分布式锁在异步系统中是一个根本不安全的概念。
分布式锁只能在正确性和活跃性二选一。

通俗来讲,如果进程在持有锁时崩溃,为了不造成死锁,会设置锁失效时间。
但是,如果进程实际上并没有死,而只是暂停或无法访问,那么锁失效会导致它被其他进程持有。暂停的进程恢复运行会以为自己还持有锁。

https://jepsen.io/analyses/etcd-3.4.3
146 天前
回复了 LiMingze 创建的主题 MySQL mysql 集群问题
Vitess
207 天前
回复了 coderhb8 创建的主题 酷工作 CoinMarketCap 上海招聘各种技术职位
被币安收购了
SE2 有电池加密了吧,只能到官方更换了
223 天前
回复了 unco020511 创建的主题 程序员 关于 https 及接口安全性方面的几个问题
1. https 解决的是数据加密传输中间人攻击,加签 /验签是业务逻辑需要对接口确认调用者是否有权限。

2. 没看明白,权限是属于业务逻辑。

3. http 是无状态协议请求需要带上状态做鉴权,本质无差别。

4. 服务器验证客户端。

5. 看具体 API 设计,抓包不能解密 https 数据,除非有证书私钥,浏览器 F12 ,请求都是你自己浏览器发的为什么不能看? https 解决的是你不能看别人发的请求。


加签 /验签 主要是做开发 API 鉴权,是那个开发者调用了 API ,仿制任意人调用。HTTPS 解决数据加密传输,传输过程中不被篡改。
225 天前
回复了 kikione 创建的主题 程序员 分布式没有全局时间
@pythonee 分布式系统需要依赖的不是时间,是确认两台机器处理事情的先后顺序,顺序有全序 偏序关系。
226 天前
回复了 kikione 创建的主题 程序员 分布式没有全局时间
226 天前
回复了 kikione 创建的主题 程序员 分布式没有全局时间
Google 的分布式数据库库用原子时钟保证误差
226 天前
回复了 kikione 创建的主题 程序员 分布式没有全局时间
只有逻辑时钟 Lamport
238 天前
回复了 kalista 创建的主题 Go 编程语言 etcd 一次性插入大量数据导致超时
etcd 是用来存 Meta 数据的
239 天前
回复了 goforwardv2 创建的主题 程序员 游戏服务器和中间件
但是就像你说的有单点故障问题。通过高可用的 ETCD 来做服务发现,通信双方直接建立连接比较好。
用 MQ 也可以实现 RPC ,性能肯定没直接通信好,MQ 本身高可用,相当于高可用版本 proxy 吧。
https://github.com/nats-rpc/nrpc
239 天前
回复了 goforwardv2 创建的主题 程序员 游戏服务器和中间件
游戏和 web 最大区别就是有状态,实时性要求高。不需要 proxy ,proxy 的唯一优点相当于做了服务发现的工作,
不需要中介可信任的价值转移
转 flink 啊
337 天前
回复了 balabalaguguji 创建的主题 知乎 挺想农村老家建个独栋别墅,求图纸
337 天前
回复了 dongfuye1 创建的主题 分享创造 分布式事务实战--go 语言的 saga 事务
以前总结的

2PC 是多 obj 的同时修改的 atomic commit 问题,consensus 一般是同一个 obj 的不同 replica 的一致问题;

在事务的上下文中,一致性( Consistency )的概念是:对数据的一组特定陈述必须始终成立。即不变量( invariants )。具体到分布式事务的上下文中这个不变量是:所有参与事务的节点状态保持一致:要么全部成功提交,要么全部失败回滚,不会出现一些节点成功一些节点失败的情况。

在分布式系统的上下文中,线性一致性( Linearizability )的概念是:多副本的系统能够对外表现地像只有单个副本一样(系统保证从任何副本读取到的值都是最新的),且所有操作都以原子的方式生效(一旦某个新值被任一客户端读取到,后续任意读取不会再返回旧值)。

分布式事务一致性会因为协调者单点引入可用性问题
为了解决可用性问题,分布式事务的节点需要在协调者故障时就新协调者选取达成共识
解决共识问题等价于实现一个线性一致的存储
解决共识问题等价于实现全序广播( total order boardcast )
Paxos/Raft 实现了全序广播

分布式事务本身的一致性是通过协调者内部的原子操作与多阶段提交协议保证的,不需要共识;但解决分布式事务一致性带来的可用性问题需要用到共识。

全序广播要求将消息按照相同的顺序,恰好传递一次,准确传送到所有节点。
1  2  3  4  5  6  7  8  9  10 ... 20  
关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1122 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 28ms · UTC 21:54 · PVG 05:54 · LAX 14:54 · JFK 17:54
Developed with CodeLauncher
♥ Do have faith in what you're doing.