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

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

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

gist.github.com/phpcyy/283bc10742b89e9daa908fc2c1270820

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

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

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

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

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

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

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

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

@lllllIIIlll

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

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

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

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

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

@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 这条消息。

@BBCCBB

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

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

@felix021 #32，是线上原先用 -race 异常，去掉了就正常，再也没发生过内存变化。原先是 1 天以内必定大幅度上升，改了之后十几天内存都是稳定的直线。

@felix021 对，性能下降我是认的，但是内存泄漏我不知道是由于我的代码中存在什么问题导致的还是 go build -race 中有什么机制导致的。

我去掉了这个 flag 之后内存就没变化过，而且标准输出中不记得有 go race 检测到的并发冲突。
还有就是如果并发访问可能会导致 panic，程序也没有 panic 记录。

实际上我的那个代码非常简单，让另外一个同事一起逐行检测过，没发现任何问题。

现在就是非常疑惑什么情形下开了 race flag 会导致内存泄漏，其实这个 case 挺难遇到的，现在也算是解决了，就是不知道更细节的坑是什么。

借楼问个和楼主曾经出现过的相似的问题，很高兴能遇见大佬，希望能够给点指点：

有一次发完 golang 项目，内存占用会持续上升，表现为某个时间段持续上升，某个时间段静止，再过一段时间又会再次上升，直至内存全部用光，操作系统杀死该进程，supervisor 重新拉起来该进程。

我也是用 pprof 分析了好久，发现没有任何异常。
然后又在本地压测什么的，都没复现这个问题。

最后真的是无可奈何，只能到处看看项目。偶然去检查了构建命令，之前我复制的测试环境的命令，把 `-race` 加上了，线上环境去掉该指令后内存泄漏问题就解决了。

当时的 golang 版本是 1.13.6，请问您觉得也是这个问题导致的吗？抑或是我可以通过什么方法找到问题根源？

如能给点指导，不胜感激。

补充一点：
我搜 go race memory leak，看到相关的 issue 已经被 close 和 fix 了。

（ ps: 最近面了头条，当然是不过，毕竟我这种分析水平确实不太行，这个问题也表现了自己能力的不足。）

江苏路到威宁路这几站吧

@dxfree 我看招行的公告也说是 8 月 1 号之前可以申请不改，但实际上我下个月的还款额已经发生变化，你可以看一下你的是不是变化了。