大概一年前，我写过一篇文章聊了聊电影《摇滚学校》——从小就玩摇滚乐，长大不会被人欺。那么今天，就要来聊聊这部电影的升级版《摇滚学校》音乐剧。

今天我们来聊一下——什么是好的“品味”？

那么大家先想一个问题，比如说你在某一个风格上，会比较喜欢一个 artist。例如 Pop 风格下的 Michael Jackson。世界上有千千万万的人喜欢 MJ。

那么我们先“假设” MJ 确实是好的，那我们能不能说喜欢 MJ 的人就有一个好的“品味”呢？

过去两年我有两个目标：

1、考出 PMP 证书。

2、好好锻炼身体。

最近一次面试时做的笔试题目，虽然很简单，但是我挺有印象的。做过很多笔试题目，这应该是第一个让我觉得挺有印象的数据库笔试题。

题目大概是这样的：

有一张表 rail 存储着上海地铁线路的信息。line 表示线路，stop 表示站点名称，sequence 表示站点在线路上的顺序。（为了简洁，我直接用 SQL 语句表示数据）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

CREATE TABLE `rail` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `line` int(10) unsigned NOT NULL,
  `stop` varchar(100) NOT NULL DEFAULT '',
  `squence` int(11) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=9 DEFAULT CHARSET=utf8;

INSERT INTO `rail`
    (`id`, `line`, `stop`, `squence`)
VALUES
  (1,1,'人民广场',10),
  (2,2,'人民广场',11),
  (3,8,'人民广场',9),
  (4,2,'世纪大道',8),
  (5,9,'世纪大道',12),
  (6,11,'曹杨路',6),
  (7,2,'静安寺',6),
  (8,7,'静安寺',9);

在 linux 没有实现 epoll 事件驱动机制之前，我们一般选择用 select 或者 poll 等 IO 多路复用的方法来实现并发服务程序。

在大数据、高并发、集群等一些名词唱的火热之年代，select 和 poll 的用武之地越来越有限了，风头已经被 epoll 占尽。

redis 采用的是基于内存的采用的是单进程单线程模型的 KV 数据库，由 C 语言编写，官方提供的数据是可以达到 100000+ 的 QPS。这个数据不比采用单进程多线程的同样基于内存的 KV 数据库 Memcached 差。

有兴趣的可以参考官方的基准程序测试《How fast is Redis？》https://redis.io/topics/benchmarks

凡事都是学问，最好都能有一定的方法论进行指导，如果只会蛮干硬上，靠本能驱动的话会造成非常可怕的后果。

千万不能迷信“有条件要上，没有条件创造条件也要上”。

周末开始刷Leetcode，是不是有点太晚了？

看过左耳朵耗子的这篇文章《技术人员的发展之路》有感而发，技术人员年纪大了之后的出路真的是一个问题。

多年以来一直在看coolshell的文章，从很早就在Google Reader里订阅了RSS。直到Google Reader死掉，coolshell都没停更过。我一直从这里面吸取着营养。

面试题：

农夫有一只羊，这只羊在第2、3年会生一只小羊，第4年不会生小羊，第5年时羊会死亡，生出来的小羊也是这个规律。求问50年后会有多少只羊？