前一段时间把这本书看完了，虽然没啥技术方面的描述，但是看完这本书还是有点收获的，记录一些我有所获的东西。
一、幂等的实现与常见问题
幂等的定义：多次执行所产生的影响均与一次执行的影响相同。那么如何实现幂等呢？简而言之，你需要一个去重机制。关于这一点有很多不同的实现方法，但是有两个很关键的因素：
a)第一个因素是幂等令牌。客户端与服务器通过什么方式来识别，这实际上是同一个请求或是同一个请求的多次尝试。这往往需要双方有一个既定的协议，比如账单号或者交易令牌这种在同一个请求上具备唯一标识的元素。这种元素通常由客户端生成。
b)第二个因素是确保唯一性。服务器端用什么机制去确保同一个请求一定不会被处理两次？最常用的做法是利用数据库。比如把幂等令牌所在的数据库表的列作为唯一性索引，这样，当你试图存储两个含有同样令牌的请求时，必定有一个会报错。这样做需要注意，简单的读检查并不一定成功，因为读与写会有竞争条件，因此还是有可能出错。
一个系统能正确处理和实现上面的两个要素，基本就达到了幂等的需求。现实系统中常见的问题有：
1)幂等令牌什么时候产生，怎样产生？
2)令牌有没有被误删的可能（比如一个支付请求中使用了，然后因为数据库回滚等原因被删除了）
3)各种竞争条件
4)对请求重试的处理
一个常见的办法是，区分正在处理的请求、处理成功和处理失败的请求。这样，当客户端重试的时候，就会根据情况直接返回或者再次处理。
5)一个系统中需要多层幂等（A-->B-->C-->.....链路的幂等性）
二、 API设计原则
1.保证API Restful的程序是100%，restful的核心是所有的行为和接口都应该是相应resource上的增删改查（CRUD）操作。
2.在请求和响应中，应该尽可能地保持参数的结构化。如果是一个哈希(hash)，就传一个哈希(不要传hash.to_string)。API的序列化和反序列化机制会将其自动序列化成字符串，多语言之间的API通常都是在序列化合反序列化机制中完成不同语言类型的转换的。
3.有关鉴权和安全的考虑，应该始终放在首位。保证对特定的用户永远只暴露相关的接口和权限。鉴权可以使用证书和白名单，也可以通过Token或Session/Cookie等方式处理。此外，所有API层的日志，都要保证不记录任何敏感信息。
4.API本身应该是与客户端无关的。所有与客户端无关的计算和处理，要尽可能在服务器端统一进行，以提高性能和一致性。
5.尽可能让API是幂等的。（具体的实现参考具体的应用场景）
评估一个API框架，可以从这几方面考虑：对访问权限的统一控制；对自动测试的支持；对请求和响应的格式以及序列化和反序列化的支持；对日志和日志过滤的支持；对自动文档生成的支持；对架构和性能的影响。
三、职业规划自问
1.你的个人价值观是什么，你最在意什么？
2.你的长期愿景是什么，五年甚至十年后，你希望自己成为什么样的人？
3.为了达到目标，你还需要掌握哪些技能或者经验？在短期内发展什么技能可能让你走的更远？
4.想实现职业梦想，或在工作中取得成功，你还需要做些什么，具备哪些技能技能？哪些技能对你来说不是必需的，但是会有很大好处？
5.你的优势和长处是什么（合作性/独立思考/行动快速/良好的产品思维等）你现在的日常工作能否让你展示长处，如果能又是如何展示的？
6.你觉得自己比别人在哪些方面做得好，能不能举出具体的例子？
四、RabbitMQ与Kafka的对比
1.Kafka是分布式的消息系统，它的高吞吐量主要取决于是否有一个比较大的服务器群，如果只是很小规模的系统，Kafka可能没法完全施展它的优势。
2.Kafka是以producer为中心的，因此对于consumer能否按需获得消息并不关心。而RabbitMQ是以broke为中心的，因此会很大程度上考虑consumer的接收能力。这意味着，如果consumer基于不同的机器或者服务器端，Kafka有绝对优势，RabbitMQ只能处理同类的consumer服务器群。
3.Kafka的消息本质上就是一个日志，它可以保证所有的消息都是有序的，但是不允许对消息的顺序进行任何改动，与之相反，RabbitMQ从某种意义上来说为每个队列都维护了消息的逻辑拷贝。
4.Kafka中的每一条消息其实都没有id的，由于全是字节流，因此消息是通过一个offset来标识的。而RabbitMQ中的每条消息都是有类型也有标识的。这样，一些传递失败的消息就可以在未来的某个时刻重新被投送和处理，这样的消息就叫做“Dead Letter”。
两个系统的设计理念，RabbitMQ是完全基于AMQP的消息代理，而Kafka是一个更通用的消息系统，很大程度上还反映了基于日志服务的一些思想。总体来说，Kafka支持高流量，但是消息就被当做简单有序的日志，侧重于共享，不能实现基于逐条消息的处理。RabbitMQ支持中小流量，但是在消息处理上有很大的灵活性。
-------------------------------------------------------------------分割线---------------------------------------------------------------------
其实看完这本书收获的更多是一些管理层的意识问题和个人成长的一些思考，因为我本人是公司第一个测试，然后招来的测试组长调岗了，公司就把我推了上来。做这个管理岗也快一年了，深知自己不是一个合格的管理者。其中性格占了很大的因素以及个人还是愿意做技术多一点(其实是不怎么擅长和人打交道，╮(╯▽╰)╭)。看书的名字就知道，这更多的是针对从技术岗转到管理岗的人，所以有这情况的人，倒是推荐把这本书读读。关于个人成长的一些思考，就不一一表述成文字了。
此时的上海真冷啊。emmm，抬头一看，外面飘着雪，瑟瑟发抖的我边打字边搓手.....
___日拱一卒，不期速成