通过源码安装ceph从release 地址选定指定的ceph源码版本，eg： v0.94.6.tar.gzhttps://github.com/ceph/ceph/releasesceph的版本看得有点乱，一会发布0.94，一会又发布10.2，得看看版本对照说明： http://docs.ceph.org.cn/releases/ 大致意思是从0.94开始，使用新的版本号，新版本号为9.0.0；下载之后，make会报错： No rule to make target `erasure-code/jerasure/jerasure/src/cauchy.c’因为版本包中不包含依赖包shell cd ceph-0.94.6/src/erasure-code/jerasure git clone https://github.com/ceph/jerasure git clone https://github.com/ceph/gf-complete到相应目录下，先安装gf-complete ```shell./configure make sudo make install ```再安装jerasureshell 1.) Install GF-Complete 2.) autoreconf --force --install 3.) ./configure 4.) make ...继续阅读 (35)

如何查看一个image的构建历史构建镜像是由一一层组成的，而每一层都对应dockefile中的一行命令； 当手上只有一个上层的应用imags，希望了解每一层都做了哪些工作时，可查看image的构建历史；示例：查看toutiao.debian:v1.1的构建历史:查询image的digest标识$cat/var/lib/docker/image/aufs/repositories.json |python -mjson.tool ..."toutiao.debian":{"toutiao.debian:v1.0":"sha256:5b8186e36a2949e441c13e61ca3595edefc2200632843ba5add6ff49ae1300c4","toutiao.debian:v1.0.1":"sha256:17f5b2db39642ab925051fd3e65ef790ba1c561214bc2a4ce35b7f4b0c448d1b","toutiao.debian:v1.1":"sha256:2709185eaaf73cdee7f64d616465fc8acc59d874782d9e217802b967612ada13"}, ...通过digest查看构建历史$cat /var/lib/docker/image/aufs/imagedb/content/sha25 ...继续阅读 (26)

删除docker registry里的images删除本地的images，我们有 docker rmi, 但删除private registry中的image，docker没有提供好用的命令行工具；而当我们需要更新registry中的镜像时，如果不删除，registry会认为我们的镜像已在库中，而忽略docker push操作（registry 2.4行为）；从registry宿主机上操作一个repo的由两部分组成，索引和分层数据；索引存放在 docker/registry/v2/repositories 中，数据存放在 docker/registry/v2/blobs 目录中； 删除的脚本干的活很简单， 从索引中找到组成这个image的分层数据hashid（digest标识），然后到blobs目录下找到删除即可；这个脚本就实现了这个功能；安装curl https://raw.githubusercontent.com/burnettk/delete-docker-registry-image/master/delete_docker_registry_image.py | sudo tee /usr/local/bin/delete_docker_registry_image >/dev/null sudo chmod a+x /usr/local/bin/delete_d ...继续阅读 (24)

ceph集群管理及客户端访问示例我们使用的是ceph的对象存储，对象存储的访问方式有两种：直接使用librados访问；通过ceph对象网关（RGW）访问；建立ceph master安装安装一个ceph比较复杂，需要装的组件比较多；如果是学习使用，使用docker镜像是个不错的选择：以下这个ceph的docker镜像安装完整的ceph组件，包括cephgw网关；https://github.com/ceph/ceph-docker(物理机安装详见官网步骤：http://docs.ceph.com/docs/master/start/)这个docker镜像启动前，需要传入宿主机的ip（10.6.26.137）；网络使用host模式，启动镜像： docker run -d -it –net=host -v /etc/ceph:/etc/ceph -v /opt/ceph:/var/lib/ceph -e MON_ IP=10.6.26.137 -e CEPH_PUBLIC_NETWORK=10.6.26.0/24配置文件存放在 /etc/ceph 目录； 数据文件存放在 /var/lib/ceph 目录；查看集群状态watch整个ceph集群的状态：ceph -w (或ceph status) ```shell root@n6-026-137:/# ceph -w cluste ...继续阅读 (27)

ceph简介ceph是个分布式文件系统，使用C++编写，没有单点故障依赖； 其他常见的分布式文件系统有：GFS、HDFS、OpenStack Swift、 、mogileFS、TFS、FastDFS等。它们都不是系统级的分布式文件系统，而是应用级的分布式文件存储服务。视频组对分布式文件系统的调研选型参考：视频存储调研总结3个基本组件Ceph最底层的存储单元是Object对象，每个Object包含元数据和原始数据。ceph架构图:最底层的RADOS就对应Ceph Storage Cluster，主要由3个组件组成： OSD、 Monitors、 MDS上层是LIBRADOS，这可以当成是访问RADOS的一个库。用户可以利用这个库开发自己的客户端应用； Ceph提供的对象存储（RADOSGW）、块设备（RBD）、文件系统（CEPHFS）也都是基于这个库完成的。OSDODS全称Object Storage Device， 也就是负责响应客户端请求返回具体数据的进程。Ceph的OSD守护进程（OSD）存储数据，处理数据复制，恢复，回填，重新调整，并通过检查其它Ceph OSD守护程序作为一个心跳 向Ceph的监视器报告一些检测信息。一个Ceph集群一般都有很多个OSD。 多个OSD组成对象存储集群；Ceph的存储集群需要至少2个OSD守护进程来保持一个active状态；MDSMDS全称C ...继续阅读 (28)

优化docker push到private registry的性能优化前，构建服务每次构建一个新的images后推送到docker registry，耗时大约1分40秒左右；（image大小780M左右） 优化之后，耗时20s左右；原因分析docker registry 在升级到 v2 后加入了很多安全相关检查，使得原来很多在 v1 already exist 的层依然要 push 到 registry,并且由于 v2 中的存储格式变成了 gzip，在镜像压缩过程中占用的时间很有可能比网络传输还要多。docker push 的大致流程：将该层文件系统压缩成本地的一个临时文件上传文件至 registry本地删除临时文件，库的元数据 传给 registryregistry 计算上传压缩包 digest 并进行校验registry 将压缩包传输至后端存储文件系统重复 1-5 直至所有层传输完毕计算镜像的 manifest 并上传至 registry 重复 3-5此外判断 already exist skip pushing 的条件变严格了，必须是本地计算过digest 且该 digest 对应 repo 存在在本地才可以。docker images由多层组成，每一层有一个唯一标识（digest），docker push时，服务端会校验，如果对应的层在服务端已经存在就不会再传输； 通过日志 ...继续阅读 (39)

关于缓冲, 主要是合理设置缓冲区大小, 尽量避免缓冲到硬盘时的情况proxy_bufferingproxy_buffering这个参数用来控制是否打开后端响应内容的缓冲区，如果这个设置为off，那么proxy_buffers和proxy_busy_buffers_size这两个指令将会失效。 但是无论proxy_buffering是否开启，对proxy_buffer_size都是生效的。proxy_buffering开启的情况下，nignx会把后端返回的内容先放到缓冲区当中，然后再返回给客户端(边收边传，不是全部接收完再传给客户端)。 临时文件由proxy_max_temp_file_size和proxy_temp_file_write_size这两个指令决定的。如果proxy_buffering关闭，那么nginx会立即把从后端收到的响应内容传送给客户端，每次取的大小为proxy_buffer_size的大小，这样效率肯定会比较低。注： proxy_buffering启用时，要提防使用的代理缓冲区太大。这可能会吃掉你的内存，限制代理能够支持的最大并发连接数。proxy_buffer_size后端服务器的相应头会放到proxy_buffer_size当中，这个大小默认等于proxy_buffers当中的设置单个缓冲区的大小。 proxy_buffer_size只是响应头的缓冲区，没 ...继续阅读 (23)

Kerberos是一种计算机网络授权协议，用来在非安全网络中，对个人通信以安全的手段进行身份认证。 采用客户端/服务器结构，并且能够进行相互认证，即客户端和服务器端均可对对方进行身份认证。关键要素KDC:Key Distribution Center – Each user and service shares a secret key with the KDC – The KDC generates and distributes session keys – Communicating parties prove to each other that theyKDC 包含两部分：– Authentication Server (AS) ● Issues “Ticket-Granting Tickets” (TGT) – Ticket Granting Server (TGS) ● Issues service tickets交互过程client向KDS发用户名和服务端名称KDC回应TGT，使用用户密码加密；client输入密码，解密TGT到手的TGT，用来和KDC通信（我已经有TGT了，属于被你信任的列表中，给我我想要的东西吧），进一步获取service tickets. img:k1.jpgKDC返回用户service tickets，用户拿service tickets ...继续阅读 (22)

docker相关文件存放在：/var/lib/docker目录下镜像的存储结构主要分两部分，一是镜像ID之间的关联，一是镜像ID与镜像名称之间的关联，前者的结构体叫Graph，后者叫TagStore./var/lib/docker/repositories-aufs TagStore的存储地方，里面有image id与reponame ，tag之间的映射关系. aufs是driver名/var/lib/graph/ 下面没有layer目录，只有每个镜像的json描述文件和layersize大小/var/lib/docker/aufs/diff/ 每层layer与其父layer之间的文件差异，有的为空，有的有一些文件(镜像实际存储的地方)/var/lib/docker/aufs/layers/ 每层layer一个文件，记录其父layer一直到根layer之间的ID，每个ID一行。大部分文件的最后一行都一样，表示继承自同一个layer./var/lib/docker/aufs/mnt/ 有容器运行时里面有数据(容器数据实际存储的地方,包含整个文件系统数据)，退出时里面为空/var/lib/docker/volumes volumes卷的存储地repositories-aufs/var/lib/docker/repositories-aufs 存放的是本地所有仓库TagStore；可以对 ...继续阅读 (37)

操作容器启动容器启动容器并启动bash（交互方式）:$dockerrun -i -t <image_name/continar_id> /bin/bash启动容器以后台方式运行(更通用的方式）：$dockerrun -d -it image_nameps：这里的 image_name 包含了tag：hello.demo.kdemo:v1.0启动容器并做端口映射# Bind TCP port 8080 of the container to TCP port 80 on 127.0.0.1 of the # host machine.# -p <host_ip>:<container_ip>$dockerrun -p 127.0.0.1:80:8080 <image> <cmd>附着到容器附着到正在运行的容器docker attach <id、container_name>进入正在运行的容器内部，同时运行bash(比attach更好用)dockerexec-t -i <id/container_name> /bin/bashps：docker exec是如此的有用，以至于我们通常是将其封装为一个脚本，放到全局可调用的地方，比如，可以写成一个indocker.sh：$catindocker.sh ...继续阅读 (18)

godep是解决包依赖的管理工具安装go get github.com/tools/godep成功安装后，在GOPATH的bin目录下会有一个godep可执行的二进制文件，后面执行的命令都是用这个，间隔这个目录加入到PATH目录中。编译和运行项目用godep管理后，要编译和运行项目的时候再用go run和go build显然就不行了，因为go命令是直接到GOPATH目录下去找第三方库。而使用godep下载的依赖库放到Godeps/workspace目录下的；godep go build XXXgodep中的go命令，就是将原先的go命令加了一层壳，执行godep go的时候，会将当前项目的workspace目录加入GOPATH变量中；godep savegodep save将项目中使用到的第三方库复制到项目的Godeps目录下。godep save 会自动扫描当前目录所属包中import的所有外部依赖库（非系统库），并查看其是否属于某个代码管理工具（比如git，hg）。若是，则把此库获取路径和当前对应的revision（commit id）记录到当前目录Godeps下的Godeps.json，同时，把不含代码管理信息（如.git目录）的代码拷贝到Godeps/_workspace/src下，用于后继godep go build等命令执行时固定查找依赖包的路径。因此，godep sa ...继续阅读 (53)

git常用命令初始化仓库新建仓库 对现有的项目进行管理，进入该项目目录并输入git initps:该命令将创建.git目录，但不会主动将现有项目中的文件纳入管理（需要自行添加）；克隆仓库git clone https://github.com/libgit2/libgit2文件的四种状态未跟踪 untracked通过以下操作到达未跟踪状态：新建文件 vi aaa 从索引区删除文件 git rm未修改 unmodified 以下操作到达未修改状态：git commit已修改 modified到达已修改状态：vi aaa已暂存 staged添加 git add查看当前状态当前状态git status状态简览git status -sPS: ‘MM’ 标记：左边M：修改并放入暂存区； 右边M：修改了还未放入暂存区查看尚未暂存的差异git diff查看已暂存的将要添加到下次提交里的内容git diff --staged三个工作区域Git仓库工作目录暂存区域基本的 Git 工作流程在工作目录中修改文件。vi aaa暂存文件，将文件的快照放入暂存区域。git add .提交更新，找到暂存区域的文件，将快照永久性存储到 Git 仓库目录。git commit -m "add file" aaa已跟踪的文件修改，直接提交到库中：git commit -a -m "update file aaa" ...继续阅读 (29)

建设私有云的目的提高服务器利用率； 现在：服务器利用率为了安全起见，都需要保持在50%以下； 通过增加服务器利用率使其更高效，实现业务弹性、水平扩展； 服务器利用率不高的主要原因是基于安全考虑，担心突发的流量对系统 造成冲击；而如果能实现业务快速的水平扩展，就解决了这个后顾之忧； 虚拟化之后，可以支持的服务快递的水平扩展；提升发布和部署的效率； 发布和部署一个服务需要小流量，然后全流量；中间遇到问题需要方便的回滚； 支持灰度发布； 发布或扩容一个服务之后，能够方便而快速的让上层应用感知；如何部署一个轻量化的私有云？这里先考虑一下最基本的私有云建设需要哪些元素，再在这个基础上提升和完善； 考虑以下几点： 选择容器； 服务发现； 容器管理；1）选择容器 容器选择docker，这个目前的主流和共识；在服务化完成后，将无状态的服务都封装在容器中；2）服务发现 有了服务，需要一个服务发现的机制；即如何让上层能够发现服务； 可选择的有（Zookeeper、etcd、consul等）； etcd、consul在我们内部都有使用；3）容器管理 第三项也是最复杂的，就是容器管理；简单的说就是从统一的入口管理容器（构建容器、启动容器等） Docker 有remote API，提供了相关的编程接口来从远程管理容器（构建容器、启动容器等）。 可以利用这写api来写一个管理工具（client/web），达到 ...继续阅读 (38)

从C++到GO刚开始接触Go语言，看了两本Go语言的书，从c++开发者的角度来看看go语言的新特性，说下自己感触较深的几点：并发编程Go语言层面支持协程，将并发业务逻辑从异步转为同步，大幅提高开发效率；在c++中，做并发编程目前主流的方案是事件驱动（单线程/多线程/多进程模型等)，而事件驱动就需要一个IO多路复用的分发器（select/epoll），这样，就造成了业务逻辑的断开，在代码层面为异步模型，比如：1).先是一段业务代码2).调用IO（业务断裂）3).IO完成后的后续处理逻辑；而go中的协程的支持让这样的开发工作就轻松多了，按照同步的方式顺序写业务逻辑，遇到IO也没关系，一个线程中可以创建成上百万个协程，这个协程阻塞了就跑下一个，不需要应用代码层面来负责IO后续调度的处理；比起自己用C/C++去封装底层或调用libevent之类的库，Go的优势是将事件机制封装成了CSP模式，编程变得方便了，但是需要付出goroutine调度的开销；ps1：Go语言标准库提供的所有系统调用操作（当然也包括所有同步IO 操作），都会出让CPU 给其他goroutine；ps2：看过网上的经验数据，同步和异步的开发效率(不是运行效率，指的是出活速度)差不多是4:1，嘿嘿，这个数据好激动~~关于事件驱动与协程在处理并发上的对比，详见不鳥萬Rio的回答：https://www.zhihu.com/q ...继续阅读 (8)

从C++到GO刚开始接触Go语言，看了两本Go语言的书，从c++开发者的角度来看看go语言的新特性，说下自己感触较深的几点：并发编程Go语言层面支持协程，将并发业务逻辑从异步转为同步，大幅提高开发效率；在c++中，做并发编程目前主流的方案是事件驱动（单线程/多线程/多进程模型等)，而事件驱动就需要一个IO多路复用的分发器（select/epoll），这样，就造成了业务逻辑的断开，在代码层面为异步模型，比如：1).先是一段业务代码2).调用IO（业务断裂）3).IO完成后的后续处理逻辑；而go中的协程的支持让这样的开发工作就轻松多了，按照同步的方式顺序写业务逻辑，遇到IO也没关系，一个线程中可以创建成上百万个协程，这个协程阻塞了就跑下一个，不需要应用代码层面来负责IO后续调度的处理；比起自己用C/C++去封装底层或调用libevent之类的库，Go的优势是将事件机制封装成了CSP模式，编程变得方便了，但是需要付出goroutine调度的开销；ps1：Go语言标准库提供的所有系统调用操作（当然也包括所有同步IO 操作），都会出让CPU 给其他goroutine；ps2：看过网上的经验数据，同步和异步的开发效率(不是运行效率，指的是出活速度)差不多是4:1，嘿嘿，这个数据好激动~~关于事件驱动与协程在处理并发上的对比，详见不鳥萬Rio的回答：https://www.zhihu.com/q ...继续阅读 (17)

网络编程中的关键问题总结总结下网络编程中关键的细节问题，包含连接建立、连接断开、消息到达、发送消息等等；连接建立包括服务端接受 (accept) 新连接和客户端成功发起 (connect) 连接。accept接受连接的问题在本文最后会聊到，这里谈谈connect的关键点；使用非阻塞连接建立需要注意：connect/select返回后，可能没有连接上；需要再次确认是否成功连接；步骤为：使用异步connect直接连接一次，因为使用了非阻塞，函数立刻返回；检查返回值，为0成功连接，否则加入到select/epoll中监控；当有写事件时，连接成功；当即可读又可写时，可能是有错误或者连接成功后有数据已经发过来；所以，此时，需要用getsockopt()读取socket的错误选项，二次确认是否真的连接成功:<code>Fcntl(sockfd, F_SETFL, flags | O_NONBLOCK); error = 0; if ( (n = connect(sockfd, saptr, salen)) < 0) if (errno != EINPROGRESS) return(-1); /* Do whatever we want while the connect is taking place. */ if (n == 0) goto ...继续阅读 (15)

网络编程中的关键问题总结总结下网络编程中关键的细节问题，包含连接建立、连接断开、消息到达、发送消息等等；连接建立包括服务端接受 (accept) 新连接和客户端成功发起 (connect) 连接。accept接受连接的问题在本文最后会聊到，这里谈谈connect的关键点；使用非阻塞连接建立需要注意：connect/select返回后，可能没有连接上；需要再次确认是否成功连接；步骤为：使用异步connect直接连接一次，因为使用了非阻塞，函数立刻返回；检查返回值，为0成功连接，否则加入到select/epoll中监控；当有写事件时，连接成功；当即可读又可写时，可能是有错误或者连接成功后有数据已经发过来；所以，此时，需要用getsockopt()读取socket的错误选项，二次确认是否真的连接成功:Fcntl(sockfd, F_SETFL, flags | O_NONBLOCK); error = 0; if ( (n = connect(sockfd, saptr, salen)) < 0) if (errno != EINPROGRESS) return(-1); /* Do whatever we want while the connect is taking place. */ if (n == 0) goto done; /* ...继续阅读 (11)

Reactor事件驱动的两种实现：面向对象 VS 函数式编程这里的函数式编程的设计以muduo为例进行对比说明；Reactor实现架构对比面向对象的设计类图如下：函数式编程以muduo为例，设计类图如下：面向对象的Reactor方案设计我们先看看面向对象的设计方案，想想为什么这么做；拿出Reactor事件驱动的模式设计图，对比来看，清晰明了；从左边开始，事件驱动，需要一个事件循环和IO分发器，EventLoop和Poller很好理解；为了让事件驱动支持多平台，Poller上加一个继承结构，实现select、epoller等IO分发器选用；Channel是要监听的事件封装类，核心成员：fd文件句柄；成员方法围绕着fd展开展开，如关注fd的读写事件、取消关注fd的读写事件；核心方法：enableReading/Writing;disableReading/Writing;以及事件到来后的处理方法：handleEvent；在OO设计这里，handleEvent设计成一个虚函数，回调上层实际的数据处理；AcceptChannel和ConnetionChannel派生自Channel，负责实际的网络数据处理；根据职责的不同而区分，AcceptChannel用于监听套接字，接收新连接请求；有新的请求到来时，生成新的socket并加入到事件循环，关注读事件；ConnetionChannel用于真 ...继续阅读 (15)

Reactor事件驱动的两种实现：面向对象 VS 函数式编程这里的函数式编程的设计以muduo为例进行对比说明；Reactor实现架构对比面向对象的设计类图如下： 函数式编程以muduo为例，设计类图如下： 面向对象的Reactor方案设计我们先看看面向对象的设计方案，想想为什么这么做；拿出Reactor事件驱动的模式设计图，对比来看，清晰明了；  从左边开始，事件驱动，需要一个事件循环和IO分发器，EventLoop和Poller很好理解；为了让事件驱动支持多平台，Poller上加一个继承结构，实现select、epoller等IO分发器选用；Channel是要监听的事件封装类，核心成员：fd文件句柄；成员方法围绕着fd展开展开，如关注fd的读写事件、取消关注fd的读写事件；核心方法：enableReading/Writing;disableReading/Writing;以及事件到来后的处理方法：handleEvent；在OO设计这里，handleEvent设计成一个虚函数，回调上层实际的数据处理；AcceptChannel和ConnetionChannel派生自Channel，负责实际的网络数据处理；根据职责的不同而区分，AcceptChannel用于监听套接字，接收新连接请求；有新的请求到来时，生成新的socket并加入到事件循环，关 ...继续阅读 (14)

单线程你别阻塞，Redis时延场景分析及应对Redis的事件循环在一个线程中处理，作为一个单线程程序，重要的是要保证事件处理的时延短，这样，事件循环中的后续任务才不会阻塞；当redis的数据量达到一定级别后（比如20G），阻塞操作对性能的影响尤为严重；下面我们总结下在redis中有哪些耗时的场景及应对方法；耗时长的命令造成阻塞keys、sort等命令keys命令用于查找所有符合给定模式 pattern 的 key，时间复杂度为O(N)， N 为数据库中 key 的数量。当数据库中的个数达到千万时，这个命令会造成读写线程阻塞数秒；类似的命令有sunion sort等操作；如果业务需求中一定要使用keys、sort等操作怎么办？解决方案：在架构设计中，有“分流”一招，说的是将处理快的请求和处理慢的请求分离来开，否则，慢的影响到了快的，让快的也快不起来；这在redis的设计中体现的非常明显，redis的纯内存操作，epoll非阻塞IO事件处理，这些快的放在一个线程中搞定，而持久化，AOF重写、Master-slave同步数据这些耗时的操作就单开一个进程来处理，不要慢的影响到快的；同样，既然需要使用keys这些耗时的操作，那么我们就将它们剥离出去，比如单开一个redis slave结点，专门用于keys、sort等耗时的操作，这些查询一般不会是线上的实时业务，查询慢点就慢点，主要是能完成任 ...继续阅读 (21)

单线程你别阻塞，Redis时延场景分析及应对Redis的事件循环在一个线程中处理，作为一个单线程程序，重要的是要保证事件处理的时延短，这样，事件循环中的后续任务才不会阻塞；当redis的数据量达到一定级别后（比如20G），阻塞操作对性能的影响尤为严重；下面我们总结下在redis中有哪些耗时的场景及应对方法；耗时长的命令造成阻塞keys、sort等命令keys命令用于查找所有符合给定模式 pattern 的 key，时间复杂度为O(N)， N 为数据库中 key 的数量。当数据库中的个数达到千万时，这个命令会造成读写线程阻塞数秒；类似的命令有sunion sort等操作；如果业务需求中一定要使用keys、sort等操作怎么办？解决方案：在架构设计中，有“分流”一招，说的是将处理快的请求和处理慢的请求分离来开，否则，慢的影响到了快的，让快的也快不起来；这在redis的设计中体现的非常明显，redis的纯内存操作，epoll非阻塞IO事件处理，这些快的放在一个线程中搞定，而持久化，AOF重写、Master-slave同步数据这些耗时的操作就单开一个进程来处理，不要慢的影响到快的；同样，既然需要使用keys这些耗时的操作，那么我们就将它们剥离出去，比如单开一个redis slave结点，专门用于keys、sort等耗时的操作，这些查询一般不会是线上的实时业务，查询慢点就慢点，主要是能完成任 ...继续阅读 (23)

负载均衡的几种常用方案总结下负载均衡的常用方案及适用场景；Round Robin 轮询调度以轮询的方式依次请求调度不同的服务器；实现时，一般为服务器带上权重；这样有两个好处：针对服务器的性能差异可分配不同的负载；当需要将某个结点剔除时，只需要将其权重设置为0即可；优点：实现简单、高效；易水平扩展；缺点：请求到目的结点的不确定，造成其无法适用于有写的场景（缓存，数据库写）应用场景：数据库或应用服务层中只有读的场景；随机方式请求随机分布到各个结点；在数据足够大的场景能达到一个均衡分布；优点：实现简单、易水平扩展；缺点：同Round Robin，无法用于有写的场景；应用场景：数据库负载均衡，也是只有读的场景；哈希方式根据key来计算需要落在的结点上，可以保证一个同一个键一定落在相同的服务器上；优点：相同key一定落在同一个结点上，这样就可用于有写有读的缓存场景；缺点：在某个结点故障后，会导致哈希键重新分布，造成命中率大幅度下降；解决：一致性哈希 or 使用keepalived保证任何一个结点的高可用性，故障后会有其它结点顶上来；应用场景：缓存，有读有写；一致性哈希在服务器一个结点出现故障时，受影响的只有这个结点上的key，最大程度的保证命中率；如twemproxy中的ketama方案；生产实现中还可以规划指定子key哈希，从而保证局部相似特征的键能分布在同一个服务器上；优点：结点故障后命 ...继续阅读 (9)

负载均衡的几种常用方案总结下负载均衡的常用方案及适用场景；Round Robin 轮询调度以轮询的方式依次请求调度不同的服务器；实现时，一般为服务器带上权重；这样有两个好处：针对服务器的性能差异可分配不同的负载；当需要将某个结点剔除时，只需要将其权重设置为0即可；优点：实现简单、高效；易水平扩展；缺点：请求到目的结点的不确定，造成其无法适用于有写的场景（缓存，数据库写）应用场景：数据库或应用服务层中只有读的场景；随机方式请求随机分布到各个结点；在数据足够大的场景能达到一个均衡分布；优点：实现简单、易水平扩展；缺点：同Round Robin，无法用于有写的场景；应用场景：数据库负载均衡，也是只有读的场景；哈希方式根据key来计算需要落在的结点上，可以保证一个同一个键一定落在相同的服务器上；优点：相同key一定落在同一个结点上，这样就可用于有写有读的缓存场景；缺点：在某个结点故障后，会导致哈希键重新分布，造成命中率大幅度下降；解决：一致性哈希 or 使用keepalived保证任何一个结点的高可用性，故障后会有其它结点顶上来；应用场景：缓存，有读有写；一致性哈希在服务器一个结点出现故障时，受影响的只有这个结点上的key，最大程度的保证命中率；如twemproxy中的ketama方案；生产实现中还可以规划指定子key哈希，从而保证局部相似特征的键能分布在同一个服务器上；优点：结点故障后命 ...继续阅读 (8)

Redis哈希表的实现要点哈希算法的选择针对不同的key使用不同的hash算法，如对整型、字符串以及大小写敏感的字符串分别使用不同的hash算法；整型的Hash算法使用的是Thomas Wang’s 32 Bit / 64 Bit Mix Function ，这是一种基于位移运算的散列方法。基于移位的散列是使用Key值进行移位操作。通常是结合左移和右移。每个移位过程的结果进行累加，最后移位的结果作为最终结果。这种方法的好处是避免了乘法运算，从而提高Hash函数本身的性能。<code>unsigned int dictIntHashFunction(unsigned int key) { key += ~(key << 15); key ^= (key >> 10); key += (key << 3); key ^= (key >> 6); key += ~(key << 11); key ^= (key >> 16); return key; }</code>字符串使用的MurmurHash算法，MurmurHash算法具有高运算性能，低碰撞率的特点，由Austin Appleby创建于2008年，现已应用到Hadoop、 ...继续阅读 (14)

Redis哈希表的实现要点哈希算法的选择针对不同的key使用不同的hash算法，如对整型、字符串以及大小写敏感的字符串分别使用不同的hash算法；整型的Hash算法使用的是Thomas Wang’s 32 Bit / 64 Bit Mix Function ，这是一种基于位移运算的散列方法。基于移位的散列是使用Key值进行移位操作。通常是结合左移和右移。每个移位过程的结果进行累加，最后移位的结果作为最终结果。这种方法的好处是避免了乘法运算，从而提高Hash函数本身的性能。unsigned int dictIntHashFunction(unsigned int key) { key += ~(key << 15); key ^= (key >> 10); key += (key << 3); key ^= (key >> 6); key += ~(key << 11); key ^= (key >> 16); return key; }字符串使用的MurmurHash算法，MurmurHash算法具有高运算性能，低碰撞率的特点，由Austin Appleby创建于2008年，现已应用到Hadoop、libstdc++、nginx、lib ...继续阅读 (23)

短网址服务设计背景短网址服务，用来将输入的一个长网址转换为一个短网址（比如附录中的案例），当用户请求这个短网址时，服务查询出真实的url;设计这么一个短网址服务，需要考虑哪些点？数据结构首先，需要考虑短网址应该如何存储，使用一个key-value结构就可以；key是生成的短网址，具有唯一性；value为原始真实网址；算法计算短网址的算法可以很简单，短网址与原始网址就只存在一个映射关系。从1开始递增来映射每一个网址；1个位上可以使用26位字母+10个数字，即36进制；当然，在计算前需要通过value来查一遍，确定是否有重复键，如果有重复，直接返回；那通过value如何快速定位是否有重复？再使用一个STL set来解决判重是个方法，有没有更好的方式？确定key的长度和value的长度value长度可以设置在500，一般的网址不会超过这个数；key: t.cn/**key的长度决定了能够支持多少个短网址；如果是5位长度,能够支持6000多万的网址，6位长度就是21亿;数据容量预估数据容量会占用多大的空间；对于这类服务，基于效率考虑，一般是全内存操作；如果单机能够装下，使用单机；如果单机无法装下，需要分片；分片策略可以根据key的递增范围来定，也可以根据取模来确定；分片策略根据key的递增范围分片优点： 扩容简单，超过1个服务器的容量后就增加一台机器；缺点：负载可能不均衡；一般后生成的短网 ...继续阅读 (18)

多线程和多进程模型的选用这里的线程指通过linux的pthread_create而产生的原生线程，线程资源很宝贵，能被操作系统的任务调度器看见的（不是python gevent、go gorouine里的概念）；我们讨论以下两种模型；多进程单线程模型（以下简称为多进程）；单进程多线程模型（以下简称为多线程）；多进程模型优点编程相对容易；通常不需要考虑锁和同步资源的问题。更强的容错性:比起多线程的一个好处是一个进程崩溃了不会影响其他进程。有内核保证的隔离：数据和错误隔离。对于使用如C/C++这些语言编写的本地代码，错误隔离是非常有用的：采用多进程架构的程序一般可以做到一定程度的自恢复；（master守护进程监控所有worker进程，发现进程挂掉后将其重启）多进程的案例nginx主流的工作模式是多进程模式（也支持多线程模型）几乎所有的web server服务器服务都有多进程的，至少有一个守护进程配合一个worker进程，例如apached,httpd等等以d结尾的进程包括init.d本身就是0级总进程，所有你认知的进程都是它的子进程；chrome浏览器也是多进程方式。redis也可以归类到“多进程单线程”模型（平时工作是单个进程，涉及到耗时操作如持久化或aof重写时会用到多个进程）多线程模型优点多线程优点：创建速度快，方便高效的数据共享共享数据：多线程间可以共享同一虚拟地址空间；多进程 ...继续阅读 (21)

异步和非阻塞今天看了篇知乎讨论，将异步和非阻塞讲的透彻；在这里整理出来；同步异步同步和异步关注的是消息通信机制同步，就是在发出一个调用时，在没有得到结果之前，该调用就不返回。但是一旦调用返回，就得到返回值了。换句话说，就是由调用者主动等待这个调用的结果。异步则相反，调用在发出之后，这个调用就直接返回了，所以没有返回结果。换句话说，当一个异步过程调用发出后，调用者不会立刻得到结果。而是在调用发出后，被调用者通过状态、通知来通知调用者，或通过回调函数处理这个调用。阻塞与非阻塞阻塞和非阻塞关注的是程序在等待调用结果（消息，返回值）时的状态.阻塞调用是指调用结果返回之前，当前线程会被挂起。调用线程只有在得到结果之后才会返回。非阻塞调用指在不能立刻得到结果之前，该调用不会阻塞当前线程。当然，这就不知道调用是否完成，一般通过轮询定期来探查调用是否完成；IO层面的同步异步在处理IO的时候，阻塞和非阻塞都是同步；如：IO多路复用（select/poll/epoll);只有使用了特殊API，才是异步IO，如：linux的AIO、Windows的IOCP .NET的beginInvoke/EndInvoke;通俗的例子买书你打电话问书店老板有没有《分布式系统》这本书，如果是同步通信机制，书店老板会说，你稍等，”我查一下"，然后开始查啊查，等查好了（可能是5秒，也可能是一天）告诉你结果（返回结 ...继续阅读 (12)

C++11带来的优雅语法自动类型推导 autoauto的自动类型推导，用于从初始化表达式中推断出变量的数据类型。通过auto的自动类型推导，可以简化我们的编程工作;auto是在编译时对变量进行了类型推导，所以不会对程序的运行效率造成不良影响;另外，似乎auto也并不会影响编译速度，因为编译时本来也要右侧推导然后判断与左侧是否匹配。auto a; // 错误，auto是通过初始化表达式进⾏类型推导，如果没有初始化表达式，就无法确定a 的类型 auto i = 1; auto d = 1.0; auto str = "Hello World"; auto ch = 'A';auto对引用的推导默认为值类型，可以指定引用修饰符设置为引用：int x = 5; int & y = x; auot z = y ;// z 为int auto & z = y; // z的类型为 int&对指针的推导默认为指针类型，当然，也可以指定*修饰符（效果一样）：int *px = &x; auto py = px; auto*py = px;推导常量const int *px = &x; auto py = px; //py的类型为 const int * const auto py = px ; //py的类型为const int *萃 ...继续阅读 (23)

C++11在时空性能方面的改进这篇我们聊聊C++11在时间和空间上的改进点；主要包括以下方面：新增的高效容器：array、forward_list以及unordered containers；以及常量表达式、静态断言和move语义；大小固定容器 arraystd::array是一个支持随机访问且大小（size）固定的容器，它是c++11中新增的容器。它有如下特点：不预留多余空间，只分配必须空间（译注：size() == capacity()）。可以使用初始化表（initializer list）的方式进行初始化。保存了自己的size信息。不支持隐式指针类型转换。可以认为它是一个很不错的内建数组类型。示例：array<int,6> a = { 1, 2, 3 }; a[3]=4; int x = a[5]; // array的默认数据元素为0，所以x的值变成0 int* p1 = a; // 错误: std::array不能隐式地转换为指针 int* p2 = a.data(); // 正确，data()得到指向第一个元素的指针可以认为array是一个紧缩版的vector，它比vector高效（没有自动空间分配），但缺少了push_back这样的神器，使得它的使用场景一般是用来替换c++内建的数组类型，而不是vector；前向列表 forward_listc++11 ...继续阅读 (20)