Overview

What is OAuth 2.0？

RFC Reader - An online reader for IETF RFCs

The OAuth (Open Authorization) 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849.

今天听了樊登对于《意志力》这本书的讲解，有了一些想法。要改善我们的意志力，首先我们需要正确的认识他，意志力其实是有限的，一旦产生了消耗，是需要时间去恢复的，并且应对不同事件的意志力其实是出自同一个账户的，这也就是为什么我们在处理了一些复杂的需要决策的事情之后，再去做其他事情的时候就会松懈、不容易坚持的原因。有一个“胡萝卜”实验，两组大学生，一组可以吃曲奇，一组只能看着曲奇吃胡萝卜，实验后让他们在坚持做一个无解的难题，前一组坚持的时间明显更长。还有一个纪录片实验，实验分为三组，第一组必需控制自己的表情，第二组需要放大他们的表情，第三组自然流露不用控制，看完纪录片后让他们握握力器，第三组的时间明显比前两组长。这是因为我们的意志力是有限的，只要使用了就会消耗，无论是控制自己的思维，控制自己的情绪，控制自己的冲动还是控制自己的表现，只要有控制我们都会消耗我们的意志力，之后就会导致我们的感觉放大，容易产生情绪波动，这也是为什么我们忙碌了一天之后很容易发脾气的原因之一。

那么我们应该怎么改善我们的意志力呢？

1. 实现表明，体能葡萄糖含量和意志力息息相关，适量的血糖有助于帮助我们维持意志力，过高或过低的血糖都会影响我们的意志力和判断力，我们可以摄入一些缓慢提供血糖的食物例如蔬菜、水果、鱼类、坚果等来维持我们血糖的稳定。
2. 最好在某个阶段只专注于一个目标，因为过多的目标会极速消耗我们的意志力，并且最好定目标的时候关注更为长期的目标，因为长期的目标可以及时调整每天的进度，不至于因为某天达不到当天的目标就产生消极心理，并且频繁制定短期目标也会更多的消耗我们的意志力。
3. 注意决策疲劳，我们做决策的时候会消耗更多的意志力，所以不要总是去做一些零散的繁杂的决策，以免到真正需要决策的时候导致决策失误。
4. 注重锻炼意志力，通过好习惯的养成可以大幅提升我们的意志力，比如每天坐直、早起，养成习惯时不要设置过高的目标，不断体会自己的进步更能提升自己的意志力。

概述

什么是 Redis

REmote DIctionary Server(Redis) 是一个由 Salvatore Sanfilippo 写的 key-value 存储系统，是跨平台的非关系型数据库。

Redis 是一个开源的使用 ANSI C 语言编写、遵守 BSD 协议、支持网络、可基于内存、分布式、可选持久性的键值对 (Key-Value) 存储数据库，并提供多种语言的 API。

Redis 通常被称为数据结构服务器，因为值（value）可以是字符串 (String)、哈希 (Hash)、列表 (list)、集合 (sets) 和有序集合 (sorted sets) 等类型。

Redis 是完全开源的，遵守 BSD 协议，是一个高性能的 key-value 数据库。

Redis 与其他 key-value 缓存产品有以下三个特点：

• Redis 支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。
• Redis 不仅仅支持简单的 key-value 类型的数据，同时还提供 list，set，zset，hash 等数据结构的存储。
• Redis 支持数据的备份，即 master-slave 模式的数据备份。

概述

消息队列（Message Queue），是分布式系统中重要的组件，它的特点是异步的，即消息的发送者和接收者不需要同时与消息队列交互。消息会保存在队列中，直到接收者取回它。

其通用的使用场景可以简单地描述为：当不需要立即获得结果，但是并发量又需要进行控制时，就可以使用消息队列。

当前使用较多的消息队列有 RabbitMQ、RocketMQ、ActiveMQ、Kafka 等，而部分数据库如 Redis、Mysql 以及 phxsql 也可实现消息队列的功能。

使用场景

消息队列在实际应用中一般包括如下四个场景：

1. 应用解耦：多应用间通过消息队列对同一消息进行处理，避免调用接口失败导致整个过程失败；
2. 异步处理：多应用对消息队列中同一消息进行处理，应用间并发处理消息，相比串行处理，减少处理时间；
3. 限流削峰：广泛应用于秒杀或抢购活动中，避免流量过大导致应用系统挂掉的情况；
4. 消息驱动的系统：系统分为消息队列、消息生产者、消息消费者，生产者负责产生消息，消费者（可能有多个）负责对消息进行处理；

缺点

1. 系统可用性降低：系统引入的外部依赖越多，越不稳定，万一 MQ 挂了可能导致整套系统崩溃。

2. 系统复杂性提高：增加了 MQ，需要考虑更多的情况，比如如何保证消息没有重复消费？如何处理消息丢失的情况？如何保证消息传递的顺序性？

3. 一致性问题：A 系统处理完了直接返回成功了，MQ 下游的 B 系统消费之后却写入失败了，数据就不一致了。

   阅读全文 »

今天听到梁宁的一个观点：产品能力是人生的一个底层能力。她说，产品能力，就是训练一个人判断信息，抓住要点，整合有限的资源，把自己的价值打造成一个产品向世界交付，并且获得回报。

作为程序员，我们首要提升的当然是自己的代码能力，但是我们一定要知道，通过自己对产品的思考输出价值是更有意义的，代码实现只是实现产品的最终步骤，软件工程告诉我们，越是前置步骤的改变成本越低，通过我们对各种技术信息的理解，可以让产品在设计之初就能够变得更加完善，这样带来的收益十分可观。

作为程序员，我们非常容易在讨论问题的时候陷入细节，经常会在需求提出的时候就想到该怎么去实现，而缺乏了对信息的判断。之前提到过，我们需要抓主要矛盾，我们不能仅仅去实现需求，那样不就成了实现需求的机器了吗？我们需要对自己的业务有独立的思考，需要在面对需求时有自己的判断，该拒绝的需求不能因为实现简单而去做，因为人的精力是有限的，做了无效的需求一定会耽误去做真正有效需求的时间和精力。所以在讨论需求时我们还需要从需求和合理性，收益性等方面加上自己的思考，做完需求时最好还能够总结和复盘，让自身在下次评估的时候能够拥有更加准确的判断能力。

其实我们都是从一无所有的状态走过来的，初入职场，我们缺乏对信息的判断和处理能力，往往会做出不准确甚至错误的判断，导致挫败和被 diss，但是通过一次次的训练，我们逐渐掌握了处理信息和抓住要点的能力，渐渐的能够建立起自己的影响圈，不断的释放自己的能力和价值，在我看来，我们每个人都在不断打造「自己」这个产品，并通过交付这个产品来获取物质的或者精神的回报。所以，想要获得更多的回报，最好的方式就是把「自己」这个产品打造的更加强大，对外释放的能力越强，影响力越大，收获也会越多。

提到事务，我们一定都不陌生，最常用的例子就是银行转账，你的银行卡有 1000 元，要给小明转 1000 元，转账过程具体到程序⾥会有⼀系列的操作，⽐如查询余额、做加减法、更新余额等，这些操作必须保证是⼀体的，不然等程序查完之后，还没做减法之前，你这 1000 块钱，完全可以借着这个时间差再查⼀次，然后再给另外⼀个朋友转账，这种情况对于银行来说是不可接受的，这个时候就需要用到事务这个概念了。

在维基百科中，对事务的定义是：事务是数据库管理系统 (DBMS) 执行过程中的一个逻辑单位，由一个有限的数据库操作序列构成。简单来说，事务就是要保证⼀组数据库操作，要么全部成功，要么全部失败。在 MySQL 中，事务⽀持是在引擎层实现的。所以并不是所有引擎都支持事务的，MyISAM 引擎被取代的重要原因就是他不支持事务。

我们平时经常使用 MySQL，那么一条 MySQL 的语句从输入到返回结果，到底经历了哪些过程呢？下面我们一起来了解一下

MySQL 逻辑架构

首先，我们一起来看一下 MySQL 的逻辑架构：

我们可以看出，MySQL 可以分为 Server 层和存储引擎层两大模块。

Server 层包括连接器、查询缓存、分析器、优化器、执⾏器等，MySQL 的⼤多数核⼼服务功能，所有内置函数，以及跨存储引擎的功能都在这⼀层实现。

存储引擎层负责数据的读写。其架构模式是插件式的，⽀持 InnoDB、MyISAM、Memory 等多个存储引擎。我们最常⽤的存储引擎是 InnoDB，它从 MySQL 5.5.5 版本开始成为了默认存储引擎。可以使用 engine=引擎名 的方式来指定使用的引擎。

近期正在看《成为技术领导者》这本书，其中对“领导力”的定义是“所谓领导力，就是创造这样一个环境，每个人都能在其中发挥出更多的能力。”，所以领导力应该注重管理过程而不是人，需要在过程中帮助大家发挥出自己更大的能力。书中提到了一个领导力的模型——MOI 模型（Motivation，Organization，Innovation），想要让团队产生变化，需要通过这三个要素来促进或抑制，Motivation 是奖励或惩罚，Organization 是通过组织架构把想法转变为现实，Innovation 是对未来的规划，想要促进变化需要三者同时作用，但是如果想阻碍变化，只需要抑制其中一条即可：M：打击激励，让人觉得变化是不受欢迎的，O：增加混乱，阻碍合作，I：阻碍思维，自己的想法第一位不听他人意见。只善于激励的人可能是明星销售或者政客，只善于组织的人可能是高效率的行政主管，只善于创新的人可能是天才但是无法与人合作。我们每个人擅长的方面都不相同，但是如果想要保证领导力的效果，需要在 MOI 三者之间寻求一个平衡，并且要相信一定存在更好的方法并不断去寻找这个方法。

说在前面

梁潇老师从一个使用 pprof 定位问题的实例 step by step 的向我们讲述了如何利用 pprof 工具的不同命令排查不同类型的问题，然后深度剖析了 pprof 采样的流程和原理。

pprof 实战

pprof 能做什么

通过 Golang 提供的 pprof 工具，我们可以很轻松的对程序的 CPU，Heap，Goroutine 等进行采样，并且 pprof 工具会帮我们分析好采样数据并且以网页或可视化的方式让我们可以很直观的观察采样结果。

说在前面

云浩老师以具体的 Golang 代码实例讲起，清晰明了地讲解了 Golang 的代码规范，然后讲解了各类 linter 的优缺点，并给出了一些最佳实践，为我们写出更加规范和一致的代码提供了指导。

Golang 代码规范

为什么我们需要代码规范

说到代码规范，其实就是不同语言的代码风格不同，为了便于理解和统一而形成的编码命名等的建议。每个语言的代码风格，大部分来自创始团队的共同”审美”，不同的语言规范甚至有完全相反的规定，但是语言风格和代码规范没有对错之分，他的作用是形成最大共识，减少沟通和理解的成本。