阶段性纠错邀请

写技术博客最重要的目的是总结归纳自己在实际工作中使用的技术知识，小弟不才写了不到两年的博客，目前一共发表八十多篇技术类文章，涵盖了负载均衡、服务治理、服务间调用、基础网络通讯、线程知识、基础存储和数据库。

这些文章大多数得到了读者的肯定，累计访问量超过50万。也算是大家对我这种通过写作进行知识学习积累方式的认同吧。在此小弟非常感谢大家，也希望将这种写作的热情持续下去。

但就像前文提到的一样，小弟在IT行业摸爬滚打也不过10几年，经历的事情也算不上多。所以在技术上难免有学艺不精的地方。例如以下两篇文章：

《架构设计：系统间通信（3）——IO通信模型和JAVA实践 上篇》

《架构设计：系统存储（17）——Redis集群方案：高可用》

虽然我的技术博客主要是用来归纳总结自己的技术知识，检查急需补漏的知识点。但既然作为公开的原创文章资源，就首先要保证做到在基本认知层面不误导广大读者。可是以上两篇文章其中一篇被读者踩了3次，另一篇被读者踩了5次而且是在不到两天的时间内。当然，这些文章允许点赞就允许点踩，一篇阅读次数上千甚至上万次的文章，被踩了1、2次，这只能说大家阅读的出发点不一样，看事物的角度不一样。

但类似以上两篇文章那样，被踩了3、5次的。那至少说明文章从基本的知识逻辑上就存在硬伤。但小弟确实不才，没有找到文章中出了怎样的硬伤会被读者如此唾弃。所以这里本人真诚邀请各位朋友帮我找找这两篇文章中的知识硬伤，并留言帮助我纠正自己的知识误区。在这里留言可以，在那两篇文章下留言也可以，我会第一时间进行回复和错误修改。

为了表示自己的真挚诚意，我会按照这两篇文章被找出来的硬伤数量为单位，每一个硬伤向壹基金捐款50元，没有上限。当然错别字或者排版问题就不劳烦各位了，攻城狮们的屌丝幽默我是深有体会的，呵呵。我会在本文发布一周后，向壹基金兑现承诺，并在本篇文章中进行截图。

最后
再次感谢一直支持我的读者朋友。

========================
今天距离该邀请发布的时间已经有一周了，在此期间网友对我关于《架构设计：系统间通信（3）——IO通信模型和JAVA实践 上篇》文章中对于Java非阻塞式的描述提出了修改意见。

具体的情况是大家常说的非阻塞方式实际上是我在那篇文章后续篇幅中描述的 多路复用方式。而我在那篇文章中提到对阻塞方式的改进，称为非阻塞方式。所以这让很多读者不能接受。在这里感谢提出建议的朋友。

但是关于《架构设计：系统存储（17）——Redis集群方案：高可用》这篇文章我却没有收到读者对我的反馈。还是希望有大神能指出文章的问题。

在这里我兑现上周的承诺：