Fade Temple

《Head First设计模式》读书笔记

设计原则 ● 找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起 把会变化的部分取出并封装起来，好让其他部分不会受到影响，这样可以导致代码的变化所引起的后果变少，代码更加可控并且不容易出问题。 大多数的模式都着眼于软件变化的主题，允许系统局部改变独立于其他部分。 ...

《风控即未来》读书笔记

风控即未来：网络支付安全和反欺诈原理（Essentials of Online Payment Security and Fraud Prevention）

北九州之行

虽然提前半年定了去日本的便宜机票，但我们俩深知彼此都是较懒的人，攻略不可能做得如此的详尽。而且我们去的是九州，远离于东京、京都等大都市，必然无法详尽浏览过多的知名景点。所以我们早早的就立下了一个这样的FLAG，以体验异国风情为主，以浏览景点为辅，做为第一次去日本（也是第一次出国）的基调，轻松自由行。

由etcd自动压缩引发的诡异问题

etcd作为优秀的分布式key-value存储系统，被广泛应用于服务发现、配置管理等需要提供稳定可靠的分布式服务的场景中。 但在面对频繁更新操作的场景时，比如对于任务调度系统，每一个任务的分配、完成都会写入一次etcd，这导致了etcd的版本号迅速增加。 由于默认情况下，etcd会保存所有版本的副本，所以随着时间的增加，etcd的内存就会不断地上涨，直到超过2G（默认最大内存是2G）后无法写入。 对我们的使用场景来说，历史版本并不是十分重要，所以为了解决这个问题，我们添加了自动压缩的机制，在启动时添加--auto-compaction-retention=24参数，即可每天压缩前一天之前的所有版本号了，这样对应的内存也会释放不少。 看似完美解决了内存的问题，但引发了另外一个问题，发现在开启压缩之后，对应的服务时不时地就会报错，并且panic掉 报错内容如下： panic: Campaign failed: etcdserver: mvcc: required revision has been compacted 示例代码如下: package main import ( "github.com/coreos/etcd/clientv3" "github.com/coreos/etcd/clientv3/concurrency" "github.com/prometheus/common/log" "golang.org/x/net/context" ) func main(){ cli, err...

那些与TIME_WAIT有关的参数

在机器上执行以下任意命令，就可以看到这个此机器上的TIME_WAIT的数量： $ netstat -apn | grep TIME_WAIT | wc -l 39871 $ ss -ant | grep TIME-WAIT | wc -l 32892 $ cat /proc/net/sockstat sockets: used 1730 TCP: inuse 576...

当我们凶狠地对待这个世界时，这个世界突然变得温文尔雅了。 – 余华《在细雨中呼喊》