今天来公司自己构建了一个Dockerfile,放在一个经常用到的项目目录里，内容如下：

# This is a comment
FROM ubuntu:14.04
MAINTAINER Docker Newbee <newbee@docker.com>
RUN apt-get -qq update
RUN apt-get -qqy install ruby ruby-dev
RUN gem install sinatra

然后执行

sudo docker build -t "cfanbo/test:v2" .

发现在构建的时候发送给 docker daemon 竟然有4G多，超极大。首先的第一反映出问题了。一个ubuntu镜像也没有这么大呀，况且现在还没有开始从远程pull 镜像呢。

那到底什么情况了呢？经过一翻搜索，发现在docker build . 的时候，会将当前目录里的内容发送给 docker daemon。只需要加一个 .dockerignore 文件，将其它内容排除掉就可以了，类似于git中的.gitignore文件的作用。

后面就想通过docker build -h 命令查看一下相关的参数，发现对于Dockerfile 文件位置需要 -f 参数指定，并非上面命令后面的.符号。那就有些疑惑了，原来学习的时候一直把.当作当前目录指定的。难道.有其它的作用，后面查看了一些文档，发现一直对 docker build 命令的过程不太了解。通过查找了一些资料才发现它的真正作用。

Docker 在运行时分为 Docker引擎（服务端守护进程） 以及 客户端工具，我们日常使用各种 docker 命令，其实就是在使用客户端工具与 Docker 引擎 进行交互。

那么当我们使用 docker build 命令来构建镜像时，这个构建过程其实是在 Docker引擎 中完成的，而不是在本机环境。

每个aliyun账号都有一个专属的镜像源

我这里安装的是 Docker Toolbox 软件，更新docker源有两种情况，一种是你还没有创建过Docker Machine，另一种是你已经创建过了Docker Machine。

一、未安装过

创建一台安装有Docker环境的Linux虚拟机，指定机器名称为default，同时配置Docker加速器地址。

$ docker-machine create –engine-registry-mirror=https://xxxx.mirror.aliyuncs.com -d virtualbox default

查看机器的环境配置，并配置到本地。然后通过Docker客户端访问Docker服务。

$ docker-machine env default $ eval “$(docker-machine env default)” $ docker info

这里 xxxx 是您的专有加速器地址

二、已安装过

登录已创建的Docker VM $ docker-machine ssh default $ sudo vi /var/lib/boot2docker/profile

在EXTRA_ARGS中添加

–registry-mirror=https://xxxx.mirror.aliyuncs.com

EXTRA_ARGS='
--label provider=virtualbox
--registry-mirror=https://fgxrbz510.mirror.aliyuncs.com
'
CACERT=/var/lib/boot2docker/ca.pem
DOCKER_HOST='-H tcp://0.0.0.0:2376'
DOCKER_STORAGE=aufs
DOCKER_TLS=auto
SERVERKEY=/var/lib/boot2docker/server-key.pem
SERVERCERT=/var/lib/boot2docker/server.pem

export "NO_PROXY=192.168.99.100"

重启Docker服务

$ sudo /etc/init.d/docker restart

有时候会提示以下错误，可以忽略。如果在连接终端执行 docker info 提示服务未启动的话，可以尝试将虚拟机手动重启一下基本可以解决，我这里用的是virtualbox

Stopping dockerd (3590)

**函数语法： **

**group_concat( [DISTINCT]  要连接的字段   [Order BY ****排序字段 **ASC/DESC]   [Separator ‘分隔符’] )

下面举例说明：

select * from goods;

+——+——+ | id| price| +——+——+ |1 | 10| |1 | 20| |1 | 20| |2 | 20| |3 | 200 | |3 | 500 | +——+——+ 6 rows in set (0.00 sec)

1. 以id分组，把price字段的值在同一行打印出来，逗号分隔(默认)

select id, group_concat(price) from goods group by id;

+——+——————–+ | id| group_concat(price) | +——+——————–+ |1 | 10,20,20| |2 | 20 | |3 | 200,500| +——+——————–+ 3 rows in set (0.00 sec)

在开发过程时，我们经常会遇到 order by 排序操作，那么你知道什么时候MySQL才会进行排序操作，什么时候不需要时间排序操作？，下面我们就从一个很小的例子中了解一下排序场景。

表结构如下：

CREATE TABLE t (
   id int(11) unsigned NOT NULL AUTO_INCREMENT,
   city varchar(16) NOT NULL,
   name varchar(16) NOT NULL,
   age int(11) NOT NULL,
   addr varchar(128) DEFAULT NULL,
   PRIMARY KEY (id),
   KEY city (city) USING BTREE
 ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这里只有一个索引city，我们执行一条SQL语句：

SELECT city, name  FROM t WHERE city='杭州' ORDER BY name LIMIT 1000;

通过Explain命令查看执行情况

发现Extra字段里有”Using filesort”，说明使用了排序，而排序必用到了sort_buffer, 这是由数据库为了专门进行排序操作而分配的一块内存。 这里的Using index conditon是指ICP特性，请参考：

下面我们专门来看一下这条语句的执行流程是如何的？在此以前我们需要了解一个概念，就是索引的特性是有序的，系统搜索时，一旦找到最后一条满足条件的记录后就立即停止，后面的记录则不再进行扫描，这样就可以用来解决全表扫描的性能问题。

这里执行过程大概如下：

1、从city索引树中第一条记录开始扫描，找到第一条满足条件的记录，获取到主键ID（每个索引都包含主键ID）。如果第一条记录的city不是”杭州”的话，则继续下一条。 2、根据主键ID进行回表，将 city, name 读取出来放在 sort_buffer 3、继续下一条并重复1、2步骤 4、直到所有满足条件的记录都放到了sort_buffer后，根据name进行排序 5、读取前1000条记录，并返回给客户端

前提

由于mac自带的python2.7（路径 /usr/bin/python） 后来手动又安装了python3.7（/usr/local/bin/python3）

两个版本共存。为了方便，直接在.zshrc文件里做了别名映射

alias python="/usr/local/bin/python3.7"

所以直接使用命令python实际上用的是3.7版本。

按照官方教程 https://docs.djangoproject.com/zh-hans/2.1/intro/install/ 安装django。发现在使用命令 pip install django 安装后发现检测不到django，很奇怪，后来发现了问题所在。

➜  ~ python
Python 3.7.1 (default, Nov  6 2018, 18:46:03)
[Clang 10.0.0 (clang-1000.11.45.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import django
Traceback (most recent call last):
  File "", line 1, in
ModuleNotFoundError: No module named 'django'

原来python2对应一个是包安装命令是 pip，而python3对应的是一个叫做pip3的命令。所以使用新的命令

pip3 install django

安装成功。

➜  ~ python
Python 3.7.1 (default, Nov  6 2018, 18:46:03)
[Clang 10.0.0 (clang-1000.11.45.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import django
>>> print(django.get_version())
2.1.3

Python中装饰器有些类似于java中的面向切片编程AOP的概念，就是对一些请求方法进行一些拦截，然后加入一些其实的逻辑。可以参与 https://blog.csdn.net/caimouse/article/details/78078189 这篇举的例子，很好理解。

http://wiki.jikexueyuan.com/project/the-python-study-notes-second-edition/decorator.html

推荐：Go的方法集详解（360云计算）

平时我们在写struct的时候，经常会用到一些方法，有些方法是我们熟悉的普通方法，在golang中我们称之为值方法，而另一种则是指针方法。

type Person struct {
    Firstname string
    Lastname string
    Age uint8
}
// 值方法
func (p Person) show() {
    fmt.Println(p.Firstname)
}
// 指针方法
func (p *Person) show2() {
    fmt.Println(p.Firstname)
}

可以看到所谓的值方法与指针方法在编写的时候，只是有无*****号的区别，这个*就是指针的意思。

那么用法又有何不同呢？

// 值方法
func (p Person) setFirstName(name string) {
    p.Firstname = name
}
// 指针方法
func (p *Person) setFirstName2(name string) {
    p.Firstname = name
}
func main() {
    p := Person{"sun", "xingfang", 30}
    //不一致的情况
    p.show() // sun 修改前
    p.setFirstName("tom")   // 值方法
    p.show() // sun, 未变化
    p.show() // sun 修改前
    p.setFirstName2("tom")  // 指针方法
    p.show() // tom 修改后的tom
}

通过上面的输出我们可以看到，当调用值方法setFirstName后，输出的还是原来的值sun，而调用指针方法 setFirstNam2后，则输出的是新值。主要原因就是值方法func (p Person)在传递总结体的时候，用的只是原来结构体的一个副本，做的任何修改也只是对副本的修改，而打印的还是原来的结构体，两者互不影响。而指针方法，传递的则是指向结构体指针的值副本，指针值一样(X012242R424)，指定的都是底层的数据结构，所以才会出现这种情况。

https://mp.weixin.qq.com/s/ZLzwQAIG6ZL88ohusOyxIQ

测试环境: 系统 win7 64位 go version: go1.10 windows/amd64

我们先看一下代码的输出

package main

import "unsafe"

func main() {
	// string
	str1 := "abc"
	println("string1:", unsafe.Sizeof(str1)) // 16
	str2 := "abcdef"
	println("string2:", unsafe.Sizeof(str2)) // 16

	// 数组
	arr1 := [...]int{1, 2, 3, 4}
	println("array1:", unsafe.Sizeof(arr1)) // 32 = 8 * 4

	arr2 := [...]int{1, 2, 3, 4, 5}
	println("array2:", unsafe.Sizeof(arr2)) // 40 = 8 * 5

	// slice 好多人分不清切片和数组的写法区别，其实只要记住[]中间是空的就是切片，反之则是数组即可
	slice1 := []int{1, 2, 3, 4}
	println("slice1:", unsafe.Sizeof(slice1)) // 24

	slice2 := []int{1, 2, 3, 4, 5}
	println("slice2:", unsafe.Sizeof(slice2)) // 24

	slice3 := []int{1, 2, 3, 4, 5, 6, 7, 8, 9, 10}
	println("slice3:", unsafe.Sizeof(slice3)) // 24
}

1、字符串类型

平时开发中，一般很少用到手动来写算法的情况，但实际上我们一直在接触一些数据结构与算法，如JAVA中的ArrayList 就用到了数据结构与算法，从名字可以看到了用到了Array这种数组结构和链表结构。下面根据目前学习的情况做一个总结。

数据结构

我们常见的数组结构一般有：

• Array数组、
• Stack栈、
• Heap堆、
• Queue队列
• Hash 哈希类型
• LinkedList 链表，其中又分为单向链表、双向链表、还有最少用的环形链表
• Tree 这个Tree分的太多了，如B-Tree、 B+Tree(mysql使用)、Binary Search Tree二叉搜索树 、AVL高度平衡树、Red Black Tree红黑树 等

http://www.bigocheatsheet.com/

算法

一般开发中用到的基本上排序算法居多，而算法大体上又分为比较排序和非比较排序。我们常用的比较排序算法有(参考： http://www.cnblogs.com/eniac12/p/5329396.html)：

• 快速排序 （Quick Sort）
• 冒泡排序 （Bubble Sort）
• 插入排序 （Insertion Sort）
• 堆排序 （Heap Sort）
• 归并排序 （Merge Sort）

而非比较排序算法有（由于排序算法时间复杂度是线性的，有时候我们也称此算法线性排序，参考 http://www.cnblogs.com/eniac12/p/5332117.html）：

• 计数排序（Counting sort）
• 基数排序 （Radix Sort）
• 桶排序 （Bucket Sort）

http://www.bigocheatsheet.com/

Bucket sort 排序 （图出自：极客时间）

计数排序 Counting sort （图出自：极客时间）

注意： 有些算法是属于稳定算法，也有些属于非稳定算法。所谓的稳定是指相同的排序值原来的顺序经过排序后，前后顺序并不改变。就像我们平时数据库中根据两个字段进行排序的时候一样。

算法时间复杂度和空间复杂度 时间复杂度： https://baike.baidu.com/item/时间复杂度/1894057 空间复杂度： https://baike.baidu.com/item/空间复杂度

https://www.cnblogs.com/alsf/p/6606287.html https://blog.csdn.net/wang_hufeng/article/details/80774761

推荐”极客时间”的两个算法专栏，其中有个专栏是视频形式的，两个专栏讲的都是特别的通俗易懂的。

https://time.geekbang.org/column/126 https://time.geekbang.org/course/intro/130

堆与栈的区别

推荐： https://www.programmerinterview.com/index.php/data-structures/difference-between-stack-and-heap/

栈是上下顺序存储的，且“先进后出LIFO”规则，只能删除顶部的元素，而堆是没有特定的顺序的存储，您可以删除任意元素。堆分配需要维护分配的内存和未分配的内存的完整记录，以及一些开销维护以减少碎片，找到足够大以适应请求大小的连续内存段，等等。内存可以随时释放，留出自由空间。有时，内存分配器将执行维护任务，比如通过将分配的内存到处移动来对内存进行碎片整理，或者在运行时进行垃圾收集——当内存不再处于作用域中时对其进行标识并释放它。

1. 栈用在线程中，程序执行时由线程创建有限数量的栈空间，当线程结束的时候会自动回收，属于系统级。 堆一般是由应用程序在启动时创建，由应用程序回收，属于应用级。

The stack is attached to a thread, so when the thread exits the stack is reclaimed. The heap is typically allocated at application startup by the runtime, and is reclaimed when the application (technically process) exits.

2. 栈的大小固定，通常在程序启动时已经确定了最大大小(部分语言支持动态扩容)。如果超出会出现“**stack overflow”**异常，经常在“递归”函数里出现。 堆是由”动态分配“的，其大小不固定，你可以在任何时间创建，再在任何时间回收（还是受限限系统虚拟内存 (ie: RAM and swap space)）。

3. 每个线程可有一个堆栈，而应用程序通常只有一个堆（尽管对于不同类型的分配有多个堆并不罕见）

4. 栈的读取速度要更快。因为分配内存的机制，只是移动指针，而堆还要做查找等操作。

Which is faster – the stack or the heap? And why?

The stack is much faster than the heap. This is because of the way that memory is allocated on the stack. Allocating memory on the stack is as simple as moving the stack pointer up.

http://thesecretlivesofdata.com/raft/

The Raft Paper

raft算法中文版： https://github.com/maemual/raft-zh_cn/blob/master/raft-zh_cn.md

k8s guide

准备

对于一个新手来说，第一步是必须了解什么是 kubernetees、 设计架构 和相关 概念。只有在了解了这些的情况下，才能更好的知道k8s中每个组件的作用以及它解决的问题。

安装工具

• minikube 参考 https://minikube.sigs.k8s.io/docs/start/
• kind 参考 https://kind.sigs.k8s.io/docs/user/quick-start/

以上是安装k8s环境的两种推荐方法，这里更推荐使用kind。主要原因是 minikube 只支持单个节点，而 kind 可以支持多个节点，这样就可以实现在一台电脑上部署的环境与生产环境一样，方便大家学习。

要实现管理控制 Kubernetes 集群资源如pod、node、service等的管理，还必须安装一个命令工具 kubectl ，请参考： https://kubernetes.io/zh/docs/tasks/tools/

学习文档

• Kubernetes 文档 https://kubernetes.io/zh/docs/home/
• Play with Kubernetes https://labs.play-with-k8s.com/
• Kubernetes中文指南/云原生应用架构实践手册 – https://jimmysong.io/kubernetes-handbook

golang实现的协程调度器，其实就是在维护一个G、P、M三者间关系的队列。

介绍（Introduction) ——————— Go 1.1最大的特色之一就是这个新的调度器，由Dmitry Vyukov贡献。新调度器让并行的Go程序获得了一个动态的性能增长，针对它我不能再做点更好的工作了，我觉得我还是为它写点什么吧。

这篇博客里面大多数东西都已经被包含在了[原始设计文档]( https://docs.google.com/document/d/1TTj4T2JO42uD5ID9e89oa0sLKhJYD0Y_kqxDv3I3XMw)中了，这个文档的内容相当广泛，但是过于技术化了。

关于新调度器，你所需要知道的都在那个设计文档中，但是我这篇博客有图片，所以更加清晰易懂。

带调度器的Go runtime需要什么？（What does the Go runtime need with a scheduler?) ——————————————————————————- 但是在我们开始看新调度器之前，我们需要理解为什么需要调度器。为什么既然操作系统能为我们调度线程了，我们又创造了一个用户空间调度器？

POSIX线程API是对现有Unix进程模型的一个非常大的逻辑扩展，而且线程获得了非常多的跟进程相同的控制。比如，线程有它自己的信号掩码，线程能够被赋予CPU affinity功能(就是指定线程只能在某个CPU上运行），线程能被添加到cgroups中，线程所用到的资源也可以被查询到。所有的这些控制增大了Go程序使用goroutine时根本不需要的特性（features）的开销，当你的程序有100,000个线程的时候，这些开销会急剧增长。

另外一个问题是，基于Go模型，操作系统不能给出特别好的决策。比如，当运行一次垃圾收集的时候，Go的垃圾收集器要求所有线程都被停止而且要求内存要处于一致状态（consistent state）。这个涉及到要等待全部运行时线程（running threads）到达一个点（point），我们事先知道在这个地方内存是一致的。

当很多被调度的线程分散在随机的点（random point）上的时候，结果就是你不得不等待他们中的大多数到达一致状态。Go调度器能够作出这样的决策，就是只在内存保持一致的点上进行调度。这就意味着，当我们为垃圾收集而停止的时候，我们只须等待在一个CPU核（CPU core）上处于活跃运行状态的线程即可。

来看看里面的各个角色（Our Cast of Characters） —————————————– 目前有三个常见的线程模型。一个是N：1的，即多个用户空间线程运行在一个OS线程M上。这个模型可以很快的进行上下文切换，但是不能利用多核系统（multi-core systems)的优势。另一个模型是1：1的，即可执行程序的一个线程匹配一个OS线程M。这个模型能够利用机器上的所有核心的优势，但是上下文切换非常慢，因为它不得不陷入OS（trap through the OS）。

Go试图通过M：N的调度器去获取这两个世界的全部优势。它在任意数目的OS线程M上调用任意数目的goroutines G。你可以快速进行上下文切换（P角色），并且还能利用你系统上所有的核心的优势。这个模型主要的缺点是它增加了调度器的复杂性。

为了完成调度任务，Go调度器使用了三个实体：

[

三角形M 表示OS线程，`它是由OS管理的可执行程序的一个线程`，就是平常提到的操作系统中的线程，而且工作起来特别像你的标准POSIX线程。在运行时代码里，它被成为M，即机器（machine）。

圆形G 表示一个goroutine。它包括栈、指令指针以及对于调用goroutines很重要的其它信息，比如阻塞它的任何channel。在可执行代码里，它被称为G。

矩形P 表示用于调用的上下文。你可以把它看作在一个单线程上运行代码的调度器的一个本地化版本。它是让我们从N：1调度器转到M：N调度器的重要部分。在运行时代码里，它被叫做P，即处理器（processor）。这部分后面会多说点。

[

我们可以从上面的图里看到两个系统线程（M），每个线程都拥有一个上下文（P），每个线程都正在运行一个goroutine（G）。为了运行goroutines，一个线程必须拥有一个上下文。

上下文（P）的数目在启动时被设置为环境变量GOMAXPROCS的值或者通过运行时函数GOMAXPROCS()来设置。通常，在你的程序执行时它不会发生变化。上下文的数目被固定的意思是，只有GOMAXPROCS个上下文正在任意点上运行Go代码。我们可以使用GOMAXPROCS调整Go进程的调用使其适合于一个单独的计算机，比如一个4核的PC中可以在4个线程上运行Go代码。

外部的灰色goroutines没在运行，但是已经准备好被调度了。它们被安排成一个叫做runqueue的列表。当go创建一个goroutine的时候，goroutine就被添加到runqueue的末端。一旦一个上下文已经运行一个goroutine到了一个点上，它就会把一个goroutine从它的runqueue给pop出来，设置栈和指令指针并且开始运行这个goroutine。

为了降低mutex竞争，每一个上下文都有它自己的runqueue。Go调度器曾经的一个版本只有一个通过mutex来保护的全局runqueue，线程们经常被阻塞来等待mutex被解除阻塞。当你有许多32核的机器而且想尽可能地压榨它们的性能时，情况就会变得相当坏。

只要所有的上下文都有goroutines要运行，调度器就能在一个稳定的状态下保持调度。但是有几个你能改变的场景。

通俗地讲，G要运行，需要绑定一个P（放在P的本地队列里），然后由与P绑定的操作系统线程M真正执行。 G切换时，只是M从G1切到G2而已，都是在用户态进行着，非常轻量，不像操作系统切换M时比较重。

你打算（系统）调用谁？（Who you gonna (sys)call?) —————————————————— 你现在可能想知道，为什么一定要有上下文？我们能不能丢掉上下文而仅仅把runqueue放到线程上？不尽然。我们用上下文的原因是如果正在运行的线程因为某种原因需要阻塞的时候，我们可以把这些上下文移交给其它线程。

我们需要阻塞的一个例子是，当我们需要调用一个系统调用的时候。因为一个线程不能既执行代码同时又阻塞到一个系统调用上，我们需要移交给对应于这个线程的上下文，以让这个上下文进行调度。

[

从上图我们能够看出，一个线程放弃了它的上下文以让另外的线程可以运行它。调度器确保有足够的线程来运行所有的上下文。上图中的M1 可能仅仅为了让它处理图中的系统调用而被创建出来，或者它可能来自一个线程池（thread cache）。这个处于系统调用中的线程将会保持在这个导致系统调用的goroutine上，因为从技术上来说，它仍然在执行，虽然阻塞在OS里了。

当这个系统调用返回的时候，这个线程必须尝试获取一个上下文来运行这个返回的goroutine，操作的正常模式是从其它所有线程中的其中一个线程中“偷”一个上下文。如果“偷盗”不成功，它就会把它的goroutine放到一个全局runqueue中，然后把自己放到线程池中或者转入睡眠状态。

这个全局runqueue是各个上下文在运行完自己的本地runqueue后用来获取新goroutine的地方。上下文也会周期性的检查这个全局runqueue上的goroutine，否则，全局runqueue上的goroutines可能得不到执行而饿死。