这篇文章主要记录一下自己对比特币的一些新的理解：1. Bitcoin为什么使用proof of work的机制来确认大多数以达成一致，2. Bitcoin如何通过巧妙的设计在一个开放的系统中保持一致性并且防止forgery double spending

参照网上的一些blog，能暂时kill掉木马进程。但是基本上过段时间又会重新启动起来（CSDN上的Blog感觉都是抄来抄去的，看着简直就是浪费时间,还是自己解决更省时间）。加上自己刚好安装了很多的环境在机器上，重装系统是不可能重装的。所以对着update.sh这个脚本一步一步排查，并且检测后台异常的进程简单的杀了一下毒，基本上算是解决了这个病毒。在此记录一下，一是可以给遇到相同问题的人一些参考，二是时刻提醒自己网络安全的重要性。

由于Raft的Safety很大程度上是由其Strong Leader的特性来保证的，使用Strong Leader虽然能简化raft协议的可理解性，但是也带来了很大的性能损失。比如raft的读写操作都必须由Leader来处理。这使得无论集群中有多少台服务器，都只有 Leader 副本能够对外提供服务，另外的Follower节点除了时刻同步数据，以及参加选举之外，所有的cpu，io和网络资源都被浪费掉了。这对读操作密集的服务来说是非常难以接收的，即使可以使用multi-raft来对数据进行分片来解决单leader性能瓶颈的问题，但是集群中2/3的cpu，io，和网络资源还是别浪费了。因此本文主要介绍raft的作者在他PhD论文[1]中提到的两种优化方法。

本文中的BTree完全是参照算法导论中的描述实现的，导论中的Btree在插入和删除删除过程中，都会提前检验节点是否可能出现不符合BTree规则的状态，提前将这些可能出现的状态消除掉。这样做的好处是，避免了插入删除过程中可能出现的递归回溯问题，使得在并发过程中加锁更加的简单。但是因为提前预判的缘故也会带来一些不必要的合并和分裂子树的消耗。至于这种避免递归回溯的实现方式，是否比递归回溯保证Tree正确性的方式更为高效？我觉得是个挺有意思的问题，在我现在看来如果是并发情况下，由于需要加锁，提前预判会比递归回溯有更好的效果。而单线程情况下则递归回溯会比提前预判有更好的效果。

孤独的人有酒喝，可流浪的人却不会唱歌。从成都到拉萨全程2000km+，历时22天，途经二十余座城市及乡镇，翻越十余座海拔4000米以上大山（两座5000米以上），穿过大渡河、雅江、金沙江、澜沧江、怒江。天葬，寺庙，雪山，草原，森林，高原，峡谷，暴雨，暴晒，逆风，冰雹，飞石，塌方，雷电，陡坡，急弯，撞车，扎胎，兴奋，痛苦，挣扎，孤独，平静。来这的每个人都怀揣着不同的目的到达，又带着不同的收获离开。而我此行的收获又是什么？希望多年以后的自己能够找到答案。

既然不能战胜时间，不如和他成为朋友：写在22岁的边上。

既然不能战胜时间，不如和他成为朋友：写在21岁的边上。

既然不能战胜时间，不如和他成为朋友：写在20岁的边上。

墨墨背单词破解带发音可登陆

本文是我博客转载的以第一篇文章，作者为黄博文。其实这篇文章我很早就看过了，今天特意转载，不单是因为他给了我很多的力量，更是因为今天自己也许下了属于我的第一个愿望，希望自己也能为了梦想而坚持。