V2EX › phpcyy 的所有回复 › 第 6 页 / 共 10 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

For Existing Member Sign In

1 2 3 4 5 6 7 8 9 10

❮

❯

2020 年 8 月 25 日

回复了 phpcyy 创建的主题 › Go 编程语言 › 求解释一个 Golang 并发 Chan 的问题

@yianing 这个超时问题关键在向 chan 写入的时候，读还未就绪，从而进入了 select 中的 default 选项；当读就绪的时候，chan 已经写入过了，从而阻塞在读取状态，直至超时，跟 Sleep 没太大关系啊。

2020 年 8 月 25 日

回复了 phpcyy 创建的主题 › Go 编程语言 › 求解释一个 Golang 并发 Chan 的问题

@sunxiansong 这里的超时确实是使用 Context 包更好，但是框架的设计者不是这么做的，我们旨在解决请求未超时但是进入了 Timeout 的情况。我认为之所以出现了 false，是因为 SomeFunc 调度的时候，gotChan 还没有进入到读状态，这时候向 someChan 写入，会进入 default 逻辑，进而导致产生了超时。

2020 年 8 月 25 日

回复了 phpcyy 创建的主题 › Go 编程语言 › 求解释一个 Golang 并发 Chan 的问题

@sunxiansong 我这个程序是对一个问题的抽象，可能抽象过度了，我说下原来的场景。

这个程序原来是在 `go SomeFunc(someChan)` 这一句发送了一个 tcp 请求，然后主程序进入等待响应阶段； SomeFunc 这个 goroutine 会执行 tcp 请求，并将结果写入 someChan 。SomeFunc 里的 `time.Sleep(10 * time.MicroSecond)` 是模拟的请求过程的请求时间。

这是我们使用的一个框架的底层源代码，我们发现了这个问题，并想着手解决，这就是前因后果，抱歉让你误解了。

2020 年 8 月 25 日

回复了 phpcyy 创建的主题 › Go 编程语言 › 求解释一个 Golang 并发 Chan 的问题

@sunxiansong 你这个并不能解决返回 false 的问题啊，我现在是想搞清楚为什么返回 false 的问题，context 的 withTimeout 和 withDeadline 在这里并不影响问题的逻辑。

2020 年 8 月 25 日

回复了 phpcyy 创建的主题 › Go 编程语言 › 求解释一个 Golang 并发 Chan 的问题

@whimsySun 问题只是缓解了，并没消除，退一步说这也不是解决问题的办法

2020 年 8 月 25 日

回复了 phpcyy 创建的主题 › Go 编程语言 › 求解释一个 Golang 并发 Chan 的问题

@whimsySun 不行的啊，我试了一下仍然出现很多 false

2020 年 8 月 25 日

回复了 phpcyy 创建的主题 › Go 编程语言 › 求解释一个 Golang 并发 Chan 的问题

@goofool 精度高了才会有上边的问题吧，你在自己电脑上跑一下看看是不是都是 true

2020 年 8 月 18 日

回复了 runking 创建的主题 › 分享发现 › 周鸿祎称有的软件会偷偷打开摄像头或者麦克风录音

建议手机厂商（ Apple 、华为、小米、OPPO 、vivo 、三星等）在操作系统层面设置一个类似于定位开关的按钮，在不使用摄像头和语音的时候能关闭摄像头和录音权限。

2020 年 7 月 10 日

回复了 cat404 创建的主题 › 程序员 › 大佬们来解答一下这个面试题（语言不限）

楼上的说的基本上是对的，我也是这个思路实现的

gist.github.com/phpcyy/283bc10742b89e9daa908fc2c1270820

2020 年 7 月 2 日

回复了 phpcyy 创建的主题 › 程序员 › 一个关于 Raft 协议的疑问

@wqlin 已经 commited 的日志一定是不会丢的，因为多数节点已经接收到了日志，所以只要这个系统还在工作，这个日志一定还是会在新的 Leader 上的。我之前的疑问是，一些老 Leader 没有 commit 的消息，其他节点也可能会将其 commit，因为他们无法区分老 Leader 是否提交了该日志。

2020 年 7 月 2 日

回复了 phpcyy 创建的主题 › 程序员 › 一个关于 Raft 协议的疑问

@wqlin 你说的是对的，我省略了一些步骤，就是返回 client 成功的时候一定是 commited + applied 的。

我提出问题的时候想的是其他节点并不知道 Leader 已经 commited 且 applied，所以如何判断是否保存之前处于 uncommited 的消息。

现在看来是他们会由于日志更新而当选 Leader，并将该消息 commit 且 apply 。

2020 年 7 月 2 日

回复了 phpcyy 创建的主题 › 程序员 › 一个关于 Raft 协议的疑问

@fishofcat 如果一个命令 client 提交了，然后 client 连接的 leader 宕机，该消息可能成功也可能失败；只要该日志在 leader 宕机之前发给了其他节点，其他节点中的有该最新日志的一台会当选为新的 leader，该命令执行成功；如果在宕机之前没有发给其他节点，该命令不会出现在其他节点，该命令会执行失败。

所以需要依赖具体应用的实现去让客户端在失败时去请求集群，获取之前命令是否执行成功。

2020 年 7 月 2 日

回复了 phpcyy 创建的主题 › 程序员 › 一个关于 Raft 协议的疑问

@fishofcat 对啊，我现在的主要问题点变成了你这个问题，客户端不知道集群已经执行了该命令，该怎么办

2020 年 7 月 2 日

回复了 phpcyy 创建的主题 › 程序员 › 一个关于 Raft 协议的疑问

@noogler67 没错，你说的都对，特别感谢。不过要澄清一点，我提出问题二的原因是，如果 B 没收到 4，C 收到了 4，C 当选 Leader 并提交了这条日志，但是 A 之前未收到多数并没有提交，也就是 client 并不知道这条日志已经提交了，感觉不太合逻辑，所以才会有这个疑问。

2020 年 7 月 2 日

回复了 phpcyy 创建的主题 › 程序员 › 一个关于 Raft 协议的疑问

@lllllIIIlll

针对 log 4 的两种情况：
1. A 没有把 log 4 复制到大多数节点 =>那么 C 在同步日志时，相当于代替 A 复制了 log 4 。
---------------------------------------------------------

C 代替 A 复制了 log 4 并 commit，即使 A 可能出现未 commit 的情况，对吗？

好像有点明白了，只保证 leader 已 commit 的必定会保存，但是原 leader 未 commit 的消息仍然会由新 leader 广播其他节点保存，但 client 可能收不到响应，不知道是不是这样？

2020 年 7 月 2 日

回复了 phpcyy 创建的主题 › 程序员 › 一个关于 Raft 协议的疑问

@lance6716 4 这个消息会持久化到 A，那其他节点若正常工作，在我描述的情况下 4 会被正常复制到其他节点吗？

2020 年 7 月 2 日

回复了 phpcyy 创建的主题 › 程序员 › 一个关于 Raft 协议的疑问

@kmyzzy 是这样的，C 的 4 这条消息是 uncommited 状态，如果它采纳了，那么可能是脏数据；如果不采纳，可能会丢失数据。除非整个集群不工作了等待 A 、B 复活。

2020 年 7 月 2 日

回复了 phpcyy 创建的主题 › 程序员 › 一个关于 Raft 协议的疑问

@BBCCBB

我的意思是 A 提交了 4，B 、C 收到了进入 uncommited 状态，需要在 A 下一次心跳的时候变为 commited，但是 A Commit 后没来得及心跳就挂了，B 、C 处于 uncommited 状态，这时候发生了重新选举。

1. 在这种情况下，如果 A 挂了，B 、C 活着，能否保证 4 这条消息不会丢失。

2. 如果 A 、B 挂了，C 活着，能否保证 4 这条消息不会丢失。

第一种情况下，B 、C 理论上仍然可以就 4 这条消息达成多数。
第二种情况下，C 无法确认 4 这条消息是否达成多数，丢弃和不丢弃无法确定，因为它不知道 B 是否保存过 4 这条消息。

2020 年 7 月 2 日

回复了 phpcyy 创建的主题 › 程序员 › 一个关于 Raft 协议的疑问

@BBCCBB

针对第二种情况，如果 A 、B 挂了，C 的 4 可能是 2 种情况，A 、C 上有，A 、B 、C 上有，如果前一种情况那么没达成共识，如果后一种情况达成了共识，C 无法断定是哪一种情况啊。

2020 年 5 月 19 日

回复了 per 创建的主题 › 分享发现 › 本站山东人多嘛？问一个相关事情

@leesymbol 600 平是带院子也算吗？房屋面积多层的话会乘以层数吗？很好奇哈~

1 2 3 4 5 6 7 8 9 10

❮

❯