默认使用redis-cli  info命令返回时默认选择的信息，但是有时候你做监控提取有效的数值的时候如果默认的可能还需要去过滤一些你用不到的无用数据，从而提取你需要的数据，这样就增加了工作量，有什么办法可以准确的提取自己想要的一些指呢，如下所示。
 
以一种易于解释（parse）且易于阅读的格式，返回关于 Redis 服务器的各种信息和统计数值。
 
通过给定可选的参数 section ，可以让命令只返回某一部分的信息，语法如下：

# redis-cli info [default|all|server....]

server 部分记录了 Redis 服务器的信息，它包含以下域：

[]redis_version : Redis 服务器版本[/][]redis_git_sha1 : Git SHA1[/][]redis_git_dirty : Git dirty flag[/][]os : Redis 服务器的宿主操作系统[/][]arch_bits : 架构（32 或 64 位）[/][]multiplexing_api : Redis 所使用的事件处理机制[/][]gcc_version : 编译 Redis 时所使用的 GCC 版本[/][]process_id : 服务器进程的 PID[/][]run_id : Redis 服务器的随机标识符（用于 Sentinel 和集群）[/][]tcp_port : TCP/IP 监听端口[/][]uptime_in_seconds : 自 Redis 服务器启动以来，经过的秒数[/][]uptime_in_days : 自 Redis 服务器启动以来，经过的天数[/][]lru_clock : 以分钟为单位进行自增的时钟，用于 LRU 管理[/]

  clients 部分记录了已连接客户端的信息，它包含以下域：

[]connected_clients : 已连接客户端的数量（不包括通过从属服务器连接的客户端）[/][]client_longest_output_list : 当前连接的客户端当中，最长的输出列表[/][]client_longest_input_buf : 当前连接的客户端当中，最大输入缓存[/][]blocked_clients : 正在等待阻塞命令（BLPOP、BRPOP、BRPOPLPUSH）的客户端的数量[/]

  memory 部分记录了服务器的内存信息，它包含以下域：

[]used_memory : 由 Redis 分配器分配的内存总量，以字节（byte）为单位[/][]used_memory_human : 以人类可读的格式返回 Redis 分配的内存总量[/][]used_memory_rss : 从操作系统的角度，返回 Redis 已分配的内存总量（俗称常驻集大小）。这个值和 top 、 ps 等命令的输出一致。[/][]used_memory_peak : Redis 的内存消耗峰值（以字节为单位）[/][]used_memory_peak_human : 以人类可读的格式返回 Redis 的内存消耗峰值[/][]used_memory_lua : Lua 引擎所使用的内存大小（以字节为单位）[/][]mem_fragmentation_ratio : used_memory_rss 和 used_memory 之间的比率[/][]mem_allocator : 在编译时指定的， Redis 所使用的内存分配器。可以是 libc 、 jemalloc 或者 tcmalloc 。[/]

在理想情况下,used_memory_rss的值应该只比used_memory稍微高一点儿。当 rss > used ，且两者的值相差较大时，表示存在（内部或外部的）内存碎片。内存碎片的比率可以通过 mem_fragmentation_ratio 的值看出。当 used > rss 时，表示 Redis 的部分内存被操作系统换出到交换空间了，在这种情况下，操作可能会产生明显的延迟。

Because Redis does not have control over how its allocations are mapped to memory pages, high used_memory_rss is often the result of a spike in memory usage.

当Redis释放内存时，分配器可能会，也可能不会，将内存返还给操作系统。如果 Redis 释放了内存，却没有将内存返还给操作系统，那么 used_memory 的值可能和操作系统显示的 Redis 内存占用并不一致。查看 used_memory_peak 的值可以验证这种情况是否发生。 persistence 部分记录了跟 RDB 持久化和 AOF 持久化有关的信息，它包含以下域：

[]loading : 一个标志值，记录了服务器是否正在载入持久化文件。[/][]rdb_changes_since_last_save : 距离最近一次成功创建持久化文件之后，经过了多少秒。[/][]rdb_bgsave_in_progress : 一个标志值，记录了服务器是否正在创建 RDB 文件。[/][]rdb_last_save_time : 最近一次成功创建 RDB 文件的 UNIX 时间戳。[/][]rdb_last_bgsave_status : 一个标志值，记录了最近一次创建 RDB 文件的结果是成功还是失败。[/][]rdb_last_bgsave_time_sec : 记录了最近一次创建 RDB 文件耗费的秒数。[/][]rdb_current_bgsave_time_sec : 如果服务器正在创建 RDB 文件，那么这个域记录的就是当前的创建操作已经耗费的秒数。[/][]aof_enabled : 一个标志值，记录了 AOF 是否处于打开状态。[/][]aof_rewrite_in_progress : 一个标志值，记录了服务器是否正在创建 AOF 文件。[/][]aof_rewrite_scheduled : 一个标志值，记录了在 RDB 文件创建完毕之后，是否需要执行预约的 AOF 重写操作。[/][]aof_last_rewrite_time_sec : 最近一次创建 AOF 文件耗费的时长。[/][]aof_current_rewrite_time_sec : 如果服务器正在创建 AOF 文件，那么这个域记录的就是当前的创建操作已经耗费的秒数。[/][]aof_last_bgrewrite_status : 一个标志值，记录了最近一次创建 AOF 文件的结果是成功还是失败。[/]

 如果 AOF 持久化功能处于开启状态，那么这个部分还会加上以下域：

[]aof_current_size : AOF 文件目前的大小。[/][]aof_base_size : 服务器启动时或者 AOF 重写最近一次执行之后，AOF 文件的大小。[/][]aof_pending_rewrite : 一个标志值，记录了是否有 AOF 重写操作在等待 RDB 文件创建完毕之后执行。[/][]aof_buffer_length : AOF 缓冲区的大小。[/][]aof_rewrite_buffer_length : AOF 重写缓冲区的大小。[/][]aof_pending_bio_fsync : 后台 I/O 队列里面，等待执行的 fsync 调用数量。[/][]aof_delayed_fsync : 被延迟的 fsync 调用数量。[/]

 stats 部分记录了一般统计信息，它包含以下域：

[]total_connections_received : 服务器已接受的连接请求数量。[/][]total_commands_processed : 服务器已执行的命令数量。[/][]instantaneous_ops_per_sec : 服务器每秒钟执行的命令数量。[/][]rejected_connections : 因为最大客户端数量限制而被拒绝的连接请求数量。[/][]expired_keys : 因为过期而被自动删除的数据库键数量。[/][]evicted_keys : 因为最大内存容量限制而被驱逐（evict）的键数量。[/][]keyspace_hits : 查找数据库键成功的次数。[/][]keyspace_misses : 查找数据库键失败的次数。[/][]pubsub_channels : 目前被订阅的频道数量。[/][]pubsub_patterns : 目前被订阅的模式数量。[/][]latest_fork_usec : 最近一次 fork() 操作耗费的毫秒数。[/]

 replication : 主/从复制信息

[]role : 如果当前服务器没有在复制任何其他服务器，那么这个域的值就是 master ；否则的话，这个域的值就是 slave 。注意，在创建复制链的时候，一个从服务器也可能是另一个服务器的主服务器。[/]

 如果当前服务器是一个从服务器的话，那么这个部分还会加上以下域：

[]master_host : 主服务器的 IP 地址。[/][]master_port : 主服务器的 TCP 监听端口号。[/][]master_link_status : 复制连接当前的状态， up 表示连接正常， down 表示连接断开。[/][]master_last_io_seconds_ago : 距离最近一次与主服务器进行通信已经过去了多少秒钟。[/][]master_sync_in_progress : 一个标志值，记录了主服务器是否正在与这个从服务器进行同步。[/]

 如果同步操作正在进行，那么这个部分还会加上以下域：

[]master_sync_left_bytes : 距离同步完成还缺少多少字节数据。[/][]master_sync_last_io_seconds_ago : 距离最近一次因为 SYNC 操作而进行 I/O 已经过去了多少秒。[/]

 如果主从服务器之间的连接处于断线状态，那么这个部分还会加上以下域：

[]master_link_down_since_seconds : 主从服务器连接断开了多少秒。[/]

 以下是一些总会出现的域：

[]connected_slaves : 已连接的从服务器数量。[/]

 对于每个从服务器，都会添加以下一行信息：

[]slaveXXX : ID、IP 地址、端口号、连接状态[/]

 cpu 部分记录了 CPU 的计算量统计信息，它包含以下域：

[]used_cpu_sys : Redis 服务器耗费的系统 CPU 。[/][]used_cpu_user : Redis 服务器耗费的用户 CPU 。[/][]used_cpu_sys_children : 后台进程耗费的系统 CPU 。[/][]used_cpu_user_children : 后台进程耗费的用户 CPU 。[/]

 commandstats : Redis 命令统计信息cluster : Redis 集群信息keyspace : 数据库相关的统计信息 除上面给出的这些值以外，参数还可以是下面这两个：

[]    all : 返回所有信息[/][]    default : 返回默认选择的信息[/]

当不带参数直接调用 INFO 命令时，使用 default 作为默认参数。
其他信息参考：http://redisdoc.com/server/info.html

项目名称：dzhops

[]使用Django框架开发的Salt Stack Web UI[/][]开发语言: python;[/][]后端框架: Django;[/][]前端框架：bootstrap/jquery；[/][]这个项目最初是我个人爱好，不过后来发现，确实能解决目前SaltStack在命令行模式下的部分缺陷；所以，现在公司已经开始在生产使用，这也直接带来一个问题，关于这套系统是否继续开源的思考；[/]

 环境：

[]RHEL 6.5 x86_64[/][]salt-master 2015.5.3[/][]salt-minion 2015.5.3[/][]salt-api 2015.5.3[/][]Django 1.6.8[/][]python 2.6.6[/][]MySQL 5.5[/][]网卡流量图使用rrdtool(v1.3.8)工具[/]

 dzhops更新记录：

[]> SaltStack相关功能（部署、更新、维护、远程）代码重构；[/][]> 视图文件拆分，新建立app：saltstack/record/managekeys；[/][]> 使用json格式通过接口传递数据，提高代码重用率；[/][]> 远程操作的jid及返回结果相关信息入库；[/][]> 对返回结果按IP进行排序；[/][]> 返回结果展示按钮增加上下距离；[/][]> 前端各选项左右对齐；[/][]> 远程命令执行返回结果显示优化；[/][]> 取消网卡流量监控；[/]

 功能介绍1.登陆页面  2.首页，显示SaltMaster所在服务器及相关组件状态信息 目前监控数据，都是通过独立的信息采集脚本完成，需要做计划任务。  3.主机列表 进入主机列表界面，可以选择机房和维护人员，使用ajax处理，每次选择会从库中重新查询符合条件的数据； 这些服务器相关的信息支持自动采集，由于目前写的方法只能完成采集任务，所以并没有将链接放出来，不过可以通过访问指定链接进行访问。  4.SaltStack 可完成如下功能：

[]服务器初始化（如模块部署等）[/][]程序、配置更新[/][]日常维护操作[/][]远程命令执行 当对Minion执行操作时，会记录本次目标Minion的数量，然后与返回结果的Minion数量进行对比，找出哪些没有返回结果；当接收到返回结果后，使用bootstrap的模态框显示结果，其中蓝色表示执行成功，红色表示有失败存在，可以点击标签查看详细情况；[/]

5.MinionKeys管理 可以分别选择已接受、待接受、已拒绝，并且可以选择机房及维护人员，进行对应的管理操作； 

6.操作记录 可以记录每次操作执行人的账号、操作、目标、及jid，并可以通过jid查看该次操作的返回结果详细情况。

更多详情可以访问项目开源地址：https://github.com/Hasal/dzhops

讲师介绍
邓伟先生，云计算工程师，4年运维经验，维护超200台服务器，每月产生PB级流量，擅长云平台高可用架构设计、大数据内容分发，公司云计算带头人，与AWS、腾讯云、阿里云深度合作。 

大家好，我叫邓伟，一直从事运维工作，今天和大家分享一下我的运维经验。记得我接手第一台服务器的时候，连linux基本命令都不会，通过百度现学现卖，装个mysql用了两天一夜。从1台服务器到200台服务器经过了什么样的阶段？从传统IDC到云服务，我们运维人需要经历什么，以后我们的工作方向是什么？
云平台的最佳实践

首先来介绍一下云上运维，关于运维我有两个原则：

一个是安全：任何服务默认关闭，默认不通过；

二个是效率：不做重复的事情，用技术实现创造。那么怎样做云上运维呢？

大家对阿里云、腾讯云这些公有云平台应该都不陌生，使用非常简单，购买一台ECS实例和一个RDS数据库就OK了。但是这不是我们想要的，这样随便找个人都可以做。

我打个比方，以前大家买笔记本电脑。都在说CPU要什么，显卡要什么，配置大家都可以做，但是工艺不是谁都可以做。曾经我遇到一个头痛的问题，当时服务器只有50台，但是需要管理配置、账户、服务、项目、IDC。。。。这个时候，我们想到开发CMDB，也就是一套运维管理系统，后来我们确实也开发出来了，但是已经被我弃用了，因为你用50%精力去做不擅长的事情，怎么可能有100%专业做的好呢？

云平台很好的帮我们解决了这个问题，需要的就是我们怎么来“巧用”。
当然，我们是基于云来创造，而不是依赖云，不是用了云就可以喝喝咖啡，看看日志。有个同事曾经问我，阿里云、腾讯云、各种云出现以后我们运维干什么，本来是运维干的事他们全干了。我是这样回答的：要么你去建设这些云的基础设施，要么你做运维开发，再或者基于云来创造价值。我选择的是后者。
这里我给大家分享一张架构图



这套架构是基于云来构建的AWS上的最佳实践，也是我们正在用的。AWS是云计算的鼻祖，累计了非常多的服务和技术。我们最常见的架构就是：服务器+数据库，服务器我们可以做负载均衡、WEB服务器的性能优化。

在AWS上用的最多的就是 EC2、ELB、S3、RDS、CDN，EC2就是一台实例，可以想象成一台服务器，可以作为Web入口。既然是入口，那就必须要考虑一个因素，就是安全。AWS的安全在我看来是所有云做得最微妙的。

首先，不管你是EC2、RDS通通不能访问，创建好一台实例，账户都不会告诉你，给你个秘钥，账户自己猜吧。当然我是问了他们的技术支持才知道账户是什么，而且这个秘钥你要是弄丢了，那对不起了，AWS不会帮你找回也无法帮你找回，就算你的业务受到多大影响，要么自己找，要么只有重置实例了。

再一个，是网络。说到安全，不得不说网络，现在基本上都用安全组了，类似系统防火墙但比防火墙更安全的玩意。还有就是漏洞，云平台提供了漏洞检测，但是不会帮你查杀，按他们的说法是，这是你的东西，我只告诉你这东西不安全，我提供的是平台，如果你是做杀毒软件的，我给你把病毒样本自动删除了，那不就是把你自己的文件给删除了吗？这就是AWS的安全逻辑，至少比国内某云前段时间自动删除用户文件的安全逻辑靠谱吧？！所以，对我们来说，放在云上更安全！

还有更强大的是，如果你要一次性配置1000台服务器，只需要写一个模板，AWS可以帮你在全球你想要的任意节点进行部署，这里500台，那里300台，都可以。AWS是一个整合平台，可以帮你免服务启动程序，就是把你的程序上传，不需要EC2，不需要java环境，直接执行，你可以做监控自愈、自动处理，也就是我们说的自动化运维。

大众点评自己做了个系统，研发提交代码，一人审核之后，代码就上线了。如果你每天都在自己做部署，那还有时间研究新技术吗？这些AWS都可以实现，让我们的业务轻松的跑起来。

云上运维
如果业务出现问题怎么办，或者说出现问题我们不知道怎么办？

我第一次被老板批就是因为监控，当时我们做了很多下载节点，电信5台、联通5台，联通有1台服务器宕机了一个月我都不知道，因为用来做下载，服务很简单，没事也不会上去看。因为只是对服务略有影响，所以当时也没有重视，一直在开发那边查问题，最后才发现这台机器在1个月里都是挂着的，然后我们就开始做监控方案。

那时候想的是自己搭建，反正开源的很多，但是试了一圈却有一点达不到要求，我做下载节点得看看各地的访问情况，不可能每个城市部署一台服务器来监控呀。我们最后选择了当时最前卫的云监控——监控宝，只要把每台服务器的下载地址填入监控宝就可以了。

这是第一步网站监控，我们不但要监控到出问题，还要自己恢复服务。

首先，你得监控这些服务，比如 tomcat／nginx／apache，不是监控服务有没有运行而是要监控他的数据，比如吞吐量，一个周期内的吞吐量，用户量多少的时候吞吐是多少。以前我们很被动，运营经常找麻烦说数据下降，现在不用了，我只要看看吞吐量发现今天下降了，马上叫运营来问怎么回事。运维要拿到主动权，有了这些数据就可以做分析，性能瓶颈也可以让运维提前感知。


大家都认为运维是背锅的，所以监控是运维必备的利器，让我们从网络层到物理层及时发现问题，化被动为主动。监控宝可以帮我们检测外部节点的访问情况，服务的性能参数，对业务有很大保障。

目前很多内容云平台是没有监控的，不是做不到，而是要私有化，所以我们依然要有自己的监控，只是不要那么复杂。服务器本身的管理还是需要我们自己做的，比如用户的监控：



用户行为的监控必须要有，这是我们用脚本编写实现的。80%的工作交给别人，20%交给自己，这样我们就有80%的时间去云端创造。

我们未来的工作就是利用云来找到与业务的契合点，来配合业务实现。现在阿里云 AWS都提供的认证，因此云不仅是一个产品，而是一个生态，只有我们深入之后，才会用好。
“小步快跑”的运维方式

云服务有个特色，没一个云服务或者产品都有他的优点和缺点，如果你是牛人就可以去平衡。例如AWS的S3是存储，CDN是分发，两者搭配使用，可以发挥各自的优势。

给大家推荐一个高可用架构：ELB负载均衡／EC2实例／RDS数据库（ redshift数据查询）／S3存储／CDN内容分发／自定义监控，这是一个框架，里面每项内容都非常多。再给大家一些福利，让大家可以实践。AWS一年的云服务是免费使用，监控宝有免费套餐（包括了我上面架构的所有内容），这里面肯定会遇到一些问题（比如我说的EC2账户都不会告诉你），这个过程很好玩，可以学到很多新思维，通过学习我们可以站在云上做创造的事情。

分享一个细节，是我深有体会，也是腾讯提出来的“小步快跑”。不要觉得现在去做这些事情没有时间，这样你会一直没有时间。我们需要集中一段时间来实现我们的短期目标，这个目标生效后，我们才会有更多的时间做更多的事情。像上面列举的服务，一个EC2文档白皮书光看都得一天时间。

以前我们做运维系统用了一年半年，然后效率还是没有提升，工程师还是在每天部署，系统也做的很慢。现在的思维，我们先用云上的，研究一个星期一个月，好了，可以用了，大家都轻松了，自然时间也出来了，总不能再干重启，换硬盘这些事情吧。

我的分享就是这样了，有任何问题都可以找我，不能解决的我们可以一起解决，共同成长。

问答
Q：您刚才提到很多东西云平台不是做不到，而是要私有化，是什么意思？

A：私有化是这样的。比如你有自己的系统，比较敏感，放在云上会有所顾虑，像AWS和阿里都提供了私有云方案。包括子网的控制，甚至可以接入你的运维系统，只要你信得过自己的运维系统就可以接入，AWS就只认你这个系统过来的认证信息。也就是说你可以用自己的系统操作自己在云上的资源，还有一种就是数据比较敏感，那就可以用子网，公网没办法进来。大家可以研究下云上的VPC。

Q：可是放在公有云平台怎么保证数据安全呢？

A：如果你放在传统IDC就放心吗，传统IDC是可以下架搬走你的服务器的。要么自建机房，要么用云。现在的云对数据都是有备份的，如果你是怕泄露就用存储桶，AWS叫S3，阿里叫OSS，S3可以把你的数据封存，并且有权限控制，封存到你自己都看不到。现在阿里好像还做不到。所以不是用云就可以，很多东西还需要研究，如果系统就部署在云上，比如分布式，出了问题要怎么看，都是需要云端运维人员去解决的。

Q：我怎么知道问题出在哪台机器上呢？

A：首先你得有监控，每台机器都需要监控。然后就是直接看每台机器的基本性能，监控宝就可以抓取你的服务基本信息和性能。分布式系统可以做轮询，比如有一台挂了，业务就不走那台服务器了。还有个东西叫域名智能解析，接口用域名来链接，谁挂了，域名就不走过去了。

加入监控与性能优化分享群
请关注以下二维码


 

当移动互联网与云计算出现后，用户不必再和企业的服务人员打交道，而是通过移动APP来直接获取服务，这就造成用户体验前置。传统的ITOM产品由于缺少有效的移动端和云端监管手段，难以发现用户体验前置带来的性能瓶颈，云智慧面向业务的端到端性能管理平台透视宝以业务的视角，对整个用户体验交付链条的每一个环节进行数据采集和分析，准确发现和定位影响用户体验的任何性能问题。

目前透视宝前端应用包含以下几个，关系图如下所示



透视宝通过主站与用户进行直接交互，为用户提供网站、移动App、主机、服务等应用的性能数据。用户认证、数据中心、文档中心应用都是直接或间接为主站提供服务，本次说明只针对透视宝主站，以下使用的前端均指主站前端服务。

服务布局
透视宝前端涉及到以下几个服务：



DataSource为后端数据系统，通常情况下的请求流程如下：用户发出请求后首先访问到Tengine，Tengine作为反向代理把请求转发到Apache，Apache调用PHP首先从Redis获取信息，若无数据则从Mysql中补充，如果请求含有主机、服务、应用等数据则会从Elasticsearch中获取。

前端应用架构
云智慧透视宝前端使用PHP作为开发语言，使用了Seaslog的日志扩展，Cwop的用户管理扩展，Redis扩展，yaf扩展(CwopServer端依赖)，其作用如下：

Seaslog HP日志模块，为开发人员提供线上线下日志情况的分析材料

Curl HP Rest服务基础，为PHP调用后端Api接口提供支持

Yaf:Cwop的Server为yaf框架开发，依赖PHP的yaf框架

Cwop:Cwop的php客户端

PHP使用目前流行的Laravel框架进行开发，前端运行流程如下所示：



Laravel提供了多语言，数据库，缓存，邮件，依赖包管理等功能，极大提高了透视宝的开发效率，以下是透视宝前端两个比较重要的功能：

✔UnitTest - Laravel集成并强化了PHP的单元测试功能，结合谷歌插件，使开发人员可以完成端到端的调试工作；

✔Artisan命令行工具 - 结合Linux的Crontab，完成了邮件发送，SmartAgent插件管理、心跳管理，告警交互等功能，单独使用时可以执行脚本完成数据库的自动化修改；

从PHP处理数据到前端页面展现我们使用了目前流行的：

✔ BootstrapCss框架,使前端页面美观自适

✔ Seajs为透视宝使用的JS模块选择加载框架

✔ Echarts作为透视宝使用的绘图工具，其适应性，可操作性都是非常良好的，透视宝所有版面的图片基本都是Echarts生成的。

数据采集流程
透视宝数据采集分为三个来源：

1.用户安装SmartAgent，插件采集，通过SendProxy发送的数据。

2.用户安装SmartAgent插件后注入JS，或手动注入JS，JS采集的数据。

3.移动端嵌入SDK，采集移动APP数据。

如下图所示：



数据采集使用Sendproxy为SmartAgent的调度器，所有SmartAgent的数据都经过Sendproxy进行统一调度发送。

其主要优势在于：

✔发送队列，保证各插件数据发送的稳定性

✔可以作为代理，部署都可联外网的主机，可以保证局域网非联网环境的数据发送

端到端实现原理
端到端是透视宝的重要功能特色，其实现原理简单地说，把请求流程中所有途经节点都记录下来，通过code堆栈和服务采集的数据还原请求所遍历的过程。



上图是一个请求拓扑，是典型的Nginx Proxy，Apache Server，PHP解析，Mysql DB的架构，请求经过了Nginx->Apache-> HP->Mysql&Api，在各节点上点击可以查看：

✔ 请求当时各服务的运行状态

✔请求的代码堆栈，SQL连接，异常信息，连接状态

实现原理如下(默认各节点已经安装了我们的SmartAgent)：

请求到Nginx时，Nginx在请求中添加唯一id标志，然后转发到Apache,Apache在请求中收到我们的id标志,则会延用此id,请求交到PHP,同理PHP，Mysql等也会在请求中延用此id标志。

PHP获取数据处理完成后请求结束，开始响应过程，PHP在响应信息中添加相同的id标志，交还给Apache，Apache返回Nginx时会在响应信息中延用此id,Nginx把内容发送到浏览器静态页面时，连同id与我们的JS文件发送到用户端，用户端JS捕获浏览器数据后发送到我们的后端DataSource处理。

透视宝获取到PHP应用带有此id的请求数据时，可以查到Nginx,Apache的请求信息，也可以获取Mysql,Api的请求信息，端到端的拓扑图也就形成了，通过id可心获取终端用户的信息。如果终点的Api也使用了我们的CodeAgent，则会转化成应用，与前面的PHP一样继续向后延伸，否则只显示请求的Api信息，获取不到Code详情。

在上述过程中，Nginx Agent,Apache Agent,Mysql Agent一直持续发送数据，所以当点击Nginx时就可以根据请求时间获取Nginx的即时状态，为用户端到端的分析提供强有力的支持。

下面提供一个前后端数据交互的完整点的简图，其中DataSource对Mysql的操作是通过透视宝应用的接口实现的




更多相关技术文章请关注云智慧官方微信（cloudwise2014）



 

 #注，本人才疏学浅，如有不对的地方，欢迎指教QQ:315111275

 一、svn服务器

1、什么是Svn
svn(subversion)是一个垮平台的开源版本控制系统。管理随时间改变的各种数据。svn会备份并记录每个文件每一次的修改更新变动，这样我们就可以把任意一个时间点的档案恢复到想要的某一个旧的版本。

2、Svn与Git
svn是集中式的管理，存在一个中央版本库，所有开发人员在本地开发所有使用的代码都来自于这个版本库，提交代码也都必须提交到这个中央版本库。

svn版本控制系统流程如下：

[]在中央库上创建或从主干复制一个分支。[/][]从中央库checkout下这个分支代码。[/][]添加自己的代码文件，修改现存的代码或者删除代码文件。[/][]commit代码，假设有人在刚刚的分支上提交了代码，你就会被提示代码过期，你得先up你得代码后在提交。up代码的时候如果出现冲突，需要解决好冲突后再进行提交。[/]

缺点：
如果无法连接到中央版本库的环境下，你无法提交代码，将代码加入版本控制，无法查看代码的历史版本，以及版本变化过程。由于代码库集中管理，因此，需要对中央版本库的存储做备份。svn的备份要备份所有代码数据以及所有更改的版本记录。

Git:
分布式的版本控制，由linus开发，所有很自然的git和linux文件系统结合比较紧密，以至于在windows上你必须使用cygwin才能使其完美的工作。

那git凭啥叫做分布式的版本控制系统呢？还是从其工作模式讲起吧。

git中没有了中央版本库的说法了，但是为了开发小组的代码共享，我们通常还是搭建一个远程的git仓库。但是和svn不同的事，开发者本地也包含了一个完整的git仓库，从某种程度上说本地的仓库和远程的仓库在身份上是等价的，没有主从之分。

如果你的项目是闭源项目，或者你习惯于以往的集中式的管理模式的话，那么在git下你也可以像svn那样的工作，只是流程中可能会增加一些步骤。

[]你在本地创建一个git库，并将其add到远程git库中。[/][]你在本地添加或者删除文件，然后commit，当然conmmit操作都是提交到本地的git库中了。（其实是提交到git目录下的objects目录中去了）[/][]将本地git库的分支push到远程git库的分支，如果这个时候远程git库中已经有别的人push过，那么远程git库将不允许你的push,这时候你需要先pull，然后如果有冲突，处理好冲突，commit到本地git库后，在push到远程git库。[/]

优点：你可以不链接远端git服务器而在本地也可以做版本控制（类似于单机版本库）。3、svn的服务端运行方式

[]独立服务器访问[/]

                       访问地址如：svn://svn.xxx.com/sadoc;

[]借助apache等http服务[/]

                      访问地址如：http://svn.xxx.com/sadoc;a、单独安装apache+svnb、csvn(apache+svn)是一个单独的整合的软件，带web界面管理的svn软件。

[]本地直接访问(在svn服务器本地访问的方式)[/]

                     访问地址：file://application/svndata/sadoc;4、svn的安装对于svn的安装的话一般没有特殊需求的话，可以直接yum安装。

[root@localhost ~]# uname -rm2.6.32-573.el6.x86_64 x86_64[root@localhost ~]# rpm -qa subversionsubversion-1.6.11-15.el6_7.x86_64如果没有的话：yum install -y subversion

5、配置svn为了可以统一管理svn，我们单独创建data和passwd文件夹

[root@localhost ~]# mkdir -p /home/svndata[root@localhost ~]# mkdir -p /home/svnpasswd

启动svn服务

[root@localhost conf]# svnserve -d -r /home/svndata/[root@localhost conf]# ps -ef|grep svnroot     22266     1  0 17:27 ?        00:00:00 svnserve -d -r /home/svndata/root     22268 22241  0 17:27 pts/6    00:00:00 grep svn[root@localhost conf]# netstat -lntup|grep svntcp        0      0 0.0.0.0:3690                0.0.0.0:*                   LISTEN      22266/svnserve

建立项目版本库，项目可以创建多个，这里只创建一个演示，

svnadmin create /home/svndata/sadoc（不可用mkdir，因为需要svn初始化很多东西）可以加 --fs-type ARG指定文件格式。

修改配置文件

[root@localhost conf]# diff svnserve.conf svnserve.conf.bak 12,13c12,13< anon-access = none#-->禁用匿名访问< auth-access = write #--?开启写权限---[quote] # anon-access = read> # auth-access = write20c20< password-db = /home/svnpasswd/passwd   # 更改目录到集中管理目录---> # password-db = passwd27c27< authz-db = /home/svnpasswd/authz     # 更改目录到集中管理目录---> # authz-db = authz

创建用户

[root@localhost ~]# cp passwd authz /home/svnpasswd/[root@localhost ~]# cd /home/svnpasswd/[root@localhost ~]# chmod 700 *[root@localhost svnpasswd]# vi passwd [size=16]# This file is an example password file for svnserve.[/size][size=16]# Its format is similar to that of svnserve.conf. As shown in the[/size][size=16]# example below it contains one section labelled [users].[/size][size=16]# The name and password for each user follow, one account per line.[/size][users]# harry = harryssecret# sally = sallyssecretqishi = qishi123    #-->添加用户linzhiling = linzhiling    #-->再添加一个**更改svnserve.conf时候需要重启svn,更改authz和passwd的时候不需要重启svn。

赋权

[root@localhost svnpasswd]# vi authz [size=16]# This file is an example authorization file for svnserve.[/size][size=16]# ======中间注释略==========[/size][size=16]# grant read ('r') access, read-write ('rw') access, or no access[/size]sagroup = qishi,linzhiling[sadoc:/]qishi = rw #添加的用户必须在passwd中存在的。linzhiling = r@sagroup = r    #添加的组要先创建。

权限格式用户组格式：             [groups],其中一个用户组可以包含一个或多个用户，用户间用逗号分隔。版本库目录格式：             [<版本库>：/项目/目录]             @<用户组> = <权限>             <用户名> = <权限>[/quote]其中，方框号内部可以有多种写法：[/],表示根目录及以下，根目录是svnserve启动时指定的，我们指定为/home/svndata,[/]就是表示对全部版本库设置的权限。 [repos:/]表示对版本库repos设置权限；[repos:/sadoc]表示对版本库repos中的sadoc项目设置权限；[repos:/sadoc/qishi] 表示对版本库repos中的sadoc项目的qishi目录设置权限；权限主题可以使用户组，用户或者，用户组在前面加@，表示全部用户。权限可以是w、r、wr和空、空表示没有任何权限.6、配置完毕重启

[root@localhost ~]# pkill svnserve[root@localhost ~]# svnserve -d -r /home/svndata/

二、svn客户端软件

windows下的svn1、windows下svn的下载地址：                https://sourceforge.net/projects/tortoisesvn/files/1.9.3/Application/TortoiseSVN-1.9.3.27038-x64-svn-1.9.3.msi/download?accel_key=61%3A1459244639%3Ahttps%253A//tortoisesvn.net/downloads.html%3A4b3a10d0%2434eeb3e5542aaed1d228cff451468585f45b0026&click_id=c32ead50-f592-11e5-bb77-0200ac1d1d9c-1&source=accel 2、安装svnwindows只需下一步下一步。3、配置链接svn[list=1][]创建一个目录[/][]鼠标右键选择目录，点击选择"svn检出(k)..."[/][]在弹出的对话框上填入以下相关信息，完成svn的链接并已完成了将文件库下载到本地。[/]

svn://xxx.xxx.xxx.xxx/sadocuser:qishipassword:qishi123

4）使用：%APPDATA%\Subversion\auth  可以查看三个子目录内保存认证信息。5）svn颜色对应的操作:

[]蓝色：提交一个修改[/][]紫色：提交一个新增项[/][]深红：提交一个删除或者替换[/][]黑色：所有其他项[/]

6）其他windows下的操作此处先略过，so easy。Linux下客户端管理

用法：svn[opthins][args] <子命令>[选项][参数]

部分常用命令

checkout(co) //从源码库取出一个工作版本的拷贝.list(ls) [--verbose]//查看文件[显示更详细的信息]cat svn://xxx.txt   //查看文件内容commit(ci) //提交当前工作拷贝的更改。这个地方是有可能出现代码冲突的。update(up)//更新。svn --help 查看所有命令

Linux下代码的检出、更新、提交

svn co svn://xxx.xxx.xxx.xxx/sadoc /mnt/svndata --username=qishi --password=qishi123    [size=16]发现已经将代码下载下来[/size]svn update svn://xxx.xxx.xxx.xxx/sadoc /mnt/svndata --username=qishi --password=qishi123    [size=16]发现已经将刚刚上传的代码更新过来了。[/size]提示：如果遇到Can't convert string from 'utf-8' to native encoding 问题是因为代码中包含了中文，需要做字符集的调整：export LC_CTYPE='en_US.UTF-8'export LC_ALL=问题解决。svn add 111.txtsvn commit -m "this is test" 111.txt [size=16]#提交文件。

常见报错[/size]提示：如果遇到Can't convert string from 'utf-8' to native encoding 问题是因为代码中包含了中文，需要做字符集的调整：

export LC_CTYPE='en_US.UTF-8'export LC_ALL=        #-->问题解决。

svn服务器上的本地访问

svn co file:///home/svndata/sadoc

三、svn进阶

1、svn目录结构的规划svn:

[]branch 分支，为测试时使用，几天以上的项目必须开分支，测试需要本分之通过，主线合并到分支通过，才能合并到主线进行测试。[/][]tag版本记录使用[/][]trunk 主线，与正式线相对应，当天不上线文件不允许提交。[/]

1）创建 主干、分支、tag目录并导入svn服务器

mkdir -p /svn/trunk /svn/branch /svn/tagsvn import /svn file:///home/svndata -m "import "

2）Linux下将主干拷贝到分支。

svn copy svn://127.0.0.1/sadoc/trunk svn://127.0.0.1/sadoc/branch/branch_cms110329 -m "create a branch by qishi modifiy" --username='qishi' --password=qishi123

2、svn钩子svn钩子就是被某些版本库事件触发的程序，例如：创建新版本或者修改未被版本控制的属性。 每个项目下的hooks都有钩子目录，去掉.tmpl扩展名就可以使用了。 提示：由于安全原因，Subversion版本库在一个空环境中执行钩子脚本--就是没有任何环境变量，甚至没有$PATH或者%PATH%。由于这个原因，许多管理员会感到困惑，他们的钩子脚本手工运行时正常，可在Subsersion中却不能运行。要注意，必须在你的钩子中设置好环境变量活为你的程序制定好绝对路径。 常用钩子脚本：

[]post-commit 在提交完成成功创建版本之后执行该钩子，提交已经完成，不可更改，因此，本脚本的返回值被忽略，提交完成时触发事物。[/][]pre-commit 提交完成前触发执行该脚本。[/][]start-commit 在客户端还没有向服务器提交数据之前，即还有建立Subsersion transaciton执行执行脚本。[/]

 非常用：

[]pre-revprop-change在修改revison属性之前[/][]post-revprop-change  在修改revison属性之后[/][]pre-unlock对文件进行解锁操作之前[/][]post-unlock 对文件进行解锁操作之后[/][]pre-lock 对文件进行加锁操作之前[/][]post-lock 对文件进行加锁操作之后[/]

 生产环境应用：

[]利用pre-commit 限制文件扩展名及大小，控制提交要输入的信息等。[/][]post-commit [/]

svn更新自动周知，MSN,邮件或者短信周知，触发checkout程序，然后实时rsync推送到服务器等。案例一：rsync与svn钩子结合实现数据实时同步某企业小案例

1、创建站点目录  mkdir /home/wwwdata2、同步代码  svn co svn://127.0.0.1/sadoc /home/wwwdata --username=qishi --password=qishi123

**写钩子脚本重点：1、环境变量 2、全路径3、编写钩子代码

#vim post-commit#!/bin/shREPOS="$1"REV="$2"export LC_CTYPE="en_US.UTF-8"export LC_ALL=LOGPATH="/mnt/log"[ ! -d ${LOGPATH} ] && mkdir ${LOGPATH} -p#update content from svnSVN=/usr/bin/svn$SVN update --username=qishi --password=qishi123 /home/wwwdataif [  $? -eq 0  ]then/usr/bin/rsync -az --delete /home/wwwdata/ /tmp/svnrsyncfi

注意：

[]给执行权限，chmod 700 post-commit[/][]注意定义环境变量[/][]尽量使用全路径[/][]在svn update之前一定要手动先checkout一下，因为首次执行需要进行 yes等确认操作。[/]

案例二：通过svn钩子限制svn上传大小、扩展名、及message长度

#!/bin/shREPOS="$1"TXN="$2"#此处更改大小限制，这里是5mMAX_SIZE=5242880#此处增加限制文件后缀名FILTER='\.(zip|rar|o|obj|tar|gz)$'# Make sure that the log message contains some text.SVNLOOK=/usr/bin/svnlookLOGMSG=`$SVNLOOK log -t "$TXN" "$REPOS"|wc -c`if [ "$LOGMSG"  -lt 9 ]thenecho -e "nLog message cann't be empty! you must input more than 8 chars as comment!" 1>$2exit 1fifiles=$($SVNLOOK changed -t $TXN $REPOS |cut -d " " -f 4-)rc=0echo "$files" |while read f;do#check file typeif echo $f|tr A-Z a-z|grep -Eq $FILTER;thenecho "File $f is not allow($FILTER) file" 1>$2exit 1;fi#check file sizefilesize=`$SVNLOOK cat -t "$TXN" "$REPOS" "$f" |wc -c`if [ "$filesize" -gt "$MAX_SIZE" ];thenecho "File $f is too large(must <=$MAX_SIZE) B" 1>&2exit 1fidone# ALL checks passed, so allow the commit.if [ $? -eq 1 ];thenexit 1elseexit 0 fi

四、代码上线方案及注意事项

上线思想：[list=1][]内网测试环境-beta环境-正式环境[/][]原则影响用户体验最小[/][]将代码先上传到临时目录，然后mv方式过去，因为mv过程很短（php代码不需要重启http服务）。[/][]尽量由运维人员管理上线，对于代码的功能性，开发人员更在意，而对于代码的性能优化和上线后服务器的稳定，运维更在意，因此，如果网站宕机问题归运维管，就要让运维控制上线更科学。否则开发随意更新，出了问题运维负责，这就错了。[/][]上线前先备份，出问题及时回滚。[/][]可采取先上线一般的应用服务器，测试无问题后 上另一半。[/]代码上线方案注意事项：[list=1][]上线流程里，办公测试环境-->IDC测试环境-->正式生产环境，所有环境中的所有软件均应版本统一，其次，应尽量单一，否侧将后患无穷，开发测试成功，IDC测试也可能有问题。[/][]开发团队小组办公内部测试环境测试（该测试环境属于开发小组维护，或定时自动更新代码），代码有问题返回给某个开发人员重新开发。[/][]有专门的测试工程师，程序有问题直接返回给开发人员，（此时返回的一般为程序的bug,称为BUG库），无为题进行IDC测试。[/][]IDC测试由测试人员和运维人员参与，叫IDCtest，进行程序的压力测试，有问题直接返回给开发人员，无问题进行线上环境上线。[/][]数台服务器代码分布上线方案举例（JAVA程序）[/]

1）假设同业务服务器有六台，将服务器分为A,B两组，A组三台，B组三台，先对A进行从负载均衡器上平滑下线，B组正常提供服务，避免服务器因上线影响业务。

2）下线过程是通过脚本将A组服务器从RS池（LVS,NGINX,HAPROXY，F5等均有平滑方案）中踢出，避免负载均衡器将请求分发给A组服务器（此时的时间应该为网站流量少时，一般为晚上）

3）将代码分发到A组服务器的站点目录下，对A组服务器上线并重启服务，并由专门的测试人员进行访问测试，测试成功后，挂上A组服务器，同时下线B组服务器，B组代码上线操作测试等和A组相同，期间也要观察上线提供的服务器状况，有问题及时回滚。

6、特别说明：如果是php程序，则上线可以简单化，直接将代码（最好全量）发布到所有上线服务器的特定目录后，分发完成后，一次性mv或ln到站点目录，当然测试少不了的，测试除了人员测试外，还有各种测试监本测试各个相关业务接口。

7、大多数门户的前段页面都已经静态化或者cache了，因此，动态的部分访问平时就不会特别多，流量低估时就更好了，再加上是平滑上下线，因此基本上对用户体验无影响的，当然也有上线出问题的情况，这个是避免不了的。

8、svn上包含代码和配置。

五、参考上线架构图

Cache系统的重要性

[]移动智能设备的时代，几十亿部设备[/][]轻易达到百万级别以上的用户[/][]极低延迟的体验[/]

 Memcached/RedisCluster的问题        --扩展、负载均衡、高可用持久化的问题       --Cache失效后的恢复时间       --Cache失效后带来的"惊群"效应 理想的Cache系统良好的Cluster支持          --Auto Sharding          --无单点失效          --读写负载均衡          --可动态扩容异步持久化 静态key分片用hash(Uid) % N  --> 分片服务器单点失效的问题 Server 2失效-->Doc 4/7/8不可用 人工维护成本      --增加节点需要更改配置      --可能需要数据迁移维护期间业务可能中断 代理

[]代理很容易成为性能瓶颈[/][]代理单点失效的问题[/][]现有代理对扩容支持不好[/]

或许可以找到更好的方法：

[]Google.com[/][]http://Stackoverflow.com/questions/13079333/[/][]Quora.com[/][]查找：Cache system sharding[/]

 Cache的特点

[]对等网-->无单节点失效[/][]vBucker-->Auto Sharding /Replica[/][]Smartclient[/]

 Couchbase Server 2.0 架构 Smart ClientClient是Cluster的一部分：                --同步服务器状态                --同步 vBucket Map代理嵌入到Client               --不再有单点失效               --不再成为性能瓶颈 总结

[]Couchbase 的对等网设计，smart client 直接获取整的集群的信息，在客户端实现负载均衡，整个集群没有单点失效，并且完全支持平行扩展。[/][]vBucket 的引入，完全实现了 auto sharding，可以方便灵活的把数据的子集在不同节点上移动，以实现集群动态管理。[/][]Couchbase 有一个非常专业的 web 管理界面，并且支持通过 RESTful API 管理，这也是 memcached, redis 不能企及的。[/][]如果只是做 key/value 的 cache，Couchbase 可以完全取代 memcached。[/][]Couchbase 已经被我们在生产环境中大量采用。[/]

 
作者：张虎 ，云巴 (yunba.io) 创始人。 JPush 创始人，原CTO。

实战分享工作F5硬件负载均衡技术视频

在移动互联网时代，我们面对的是更多的客户端，更低的请求延迟，这当然需要对数据做大量的 Cache 以提高读写速度。
术语
节点：指集群里的一台服务器。
 
现有 Cache 系统的特点
目前业界使用得最多的 Cache 系统主要是 memcached 和 redis。 这两个 Cache 系统都有都有很大的用户群，可以说是比较成熟的解决方案，也是很多系统当然的选择。 不过，在使用 memcached 和 redis 过程中，还是碰到了不少的问题和局限：

[]Cluster 支持不够。在扩容、负载均衡、高可用等方面存在明显不足。[/][]持久化支持不好，出现问题后恢复的代价大。memcached 完全不支持持久化，redis 的持久化会造成系统间歇性的负载很高。[/]

 理想 Cache 系统良好的 cluster 支持

[]Key 可以动态分散（Auto Sharding）在不同的服务器上，可以通过动态添加服务器节点增加系统容量。[/][]没有单点失效，任何一个单点都不会造成数据不可访问。[/][]读写负载可以均匀分布在系统的不同节点上。[/]

支持异步持久化支持

[]方便快速恢复，甚至可以直接用作 key/value 数据库。 经常在跟业界朋友交流时，会提到用 key 分段的方法来做容量扩展以及负载均衡。但是用静态的 key 分段会有不少问题：[/][]Cache 系统本身及使用 cache 的客户端都需要预设一个分段逻辑，这个逻辑后期如果需要调整将会非常困难。不能解决单点失效的问题，还需要额外的手段。运维需要更多的人为参与，避免 key 超出现有分区，一旦出现 key 找不到对应服务器，访问直接失败。[/]

 最接近需求的系统：Couchbase基于这些想法，我花了几天时间在 google, stack overflow, quora 上看了很多大家关于 cache cluster 的讨论，找到一个比较新系统 Couchbase。  Couchbase日前宣布推出其新版的NoSQL数据服务器——Couchbase Server。该产品基于Apache CouchDB，并整合了GeoCouch（一个基于Erlang、紧密集成的地理空间索引系统，可支持LBS应用）。 Couchbase公司是由CouchOne与Membase合并组成，但合并后推出的第一款产品Couchbase Server并没有包含Membase的任何技术。Couchbase Server分为企业版和社区版两个版本，其中企业版经过了严格的QA过程，并有技术支持和维护保障，但两者的API完全兼容。Couchbase Server企业版本每节点定价范围从999美元（10×5技术支持，5次），到4499美元（24×7技术支持，无限次）。 据悉，所有企业版和社区版都提供包括Red Hat，Ubuntu Linux和Windows在内的各操作系统版本。Mac OS X有社区版。 此外，Couchbase还宣布成立顾问委员会为其提供战略和技术上的指导，委员会成员包括PostgreSQL开发核心团队成员Josh Berkus，SQLite的创始人Richard Hipp，HTTP与REST创始人Roy Fielding，Zynga CTO Cadir Lee，《软件人才管理的艺术》作者Michael Loop，Cloudera CEO Michael Olson，YSlow的作者、Google性能专家Steve Souders等。 Couchbase 的集群设计对等网Couchbase 群集所有点都是对等的，只是在创建群或者加入集群时需要指定一个主节点，一旦结点成功加入集群，所有的结点对等。 对等网的优点是，集群中的任何节点失效，集群对外提供服务完全不会中断，只是集群的容量受影响。 Smart Client 由于 couchbase 是对等网集群，所有的节点都可以同时对客户端提供服务，这就需要有方法把集群的节点信息暴露给客户端，couchbase 提供了一套机制，客户端可以获取所有节点的状态以及节点的变动，由客户端根据集群的当前状态计算 key 所在的位置。 vBucket vBucket 概念的引入，是 couchbase 实现 auto sharding，在线动态增减节点的重要基础。 简单的解释 vBucket 可以从静态分片开始说起，静态分片的做法一般是用 key 算出一个 hash，得到对应的服务器，这个算法很简单，也容易理解。如以下代码所示：

servers = ['server1:11211', 'server2:11211', 'server3:11211']server_for_key(key) = servers[hash(key) % servers.length]

但也有几个问题：

[]如果一台服务器失效，会造成该分片的所有 key 失效。[/][]如果服务器容量不同，管理非常麻烦。[/][]前面提到过，运维、配置非常不方便。[/]

为了把 key 跟服务器解耦合，couchbase 引入了 vBucket。可以说 vBucket 代表一个 cache 子集，主要特点：

[]key hash 对应一个 vBucket，不再直接对应服务器。[/][]集群维护一个全局的 vBucket 与服务器对应表。[/][]前面提到的 smart client 重要的功能就是同步 vBucket 表。[/]

如以下代码所示：

servers = ['server1:11211', 'server2:11211', 'server3:11211']vbuckets = [0, 0, 1, 1, 2, 2]server_for_key(key) = servers[vbuckets[hash(key) % vbuckets.length]]

由于 vBucket 把 key 跟服务器的静态对应关系解耦合，基于 vBucket 可以实现一些非常强大有趣的功能，例如：

[]Replica，以 vBucket 为单位的主从备份。如果某个节点失效，只需要更新 vBucket 映射表，马上启用备份数据。[/][]动态扩容。新增加一个节点后，可以把部分 vBucket 转移到新节点上，并更新 vBucket 映射表。[/]

 性能测试

单机支持300k/OPS,内存消耗主要是bukket占用,到300k/OPS负载也不高，它的xdcr同步4千万的数据不到5分钟。 总结

[]Couchbase 的对等网设计，smart client 直接获取整的集群的信息，在客户端实现负载均衡，整个集群没有单点失效，并且完全支持平行扩展。[/][]vBucket 的引入，完全实现了 auto sharding，可以方便灵活的把数据的子集在不同节点上移动，以实现集群动态管理。[/][]Couchbase 有一个非常专业的 web 管理界面，并且支持通过 RESTful API 管理，这也是 memcached, redis 不能企及的。[/][]如果只是做 key/value 的 cache，Couchbase 可以完全取代 memcached。[/][]Couchbase 已经被我们在生产环境中大量采用。[/]

 

原文链接：http://zhang.hu/couchbase/
作者：张虎 云巴 (yunba.io) 创始人, JPush 联合创始人，原CTO。

本文来源于全球最大的职业社交网站LinkedIn领英，文章版权归作者本人所有。
 
今天LinkedIn宣布开源Dr. Elephant，Dr. Elephant能够很好地帮助用户理解、分析和优化Hadoop和Spark的工作流。LinkedIn在去年第八届Hadoop Summit上第一次在社区呈现。

动机​
Hadoop是一个分布式数据存储和大数据处理框架，体量大、组件复杂，因而每个组件的性能优化就显得异常重要。在优化底层硬件资源，网络架构，OS和其它堆栈的同时，也需要对集群上运行的任务进行优化。
 
什么是Dr. Elephant?
Dr. Elephant是一个Hadoop 和Spark的性能监控和调优工具。Dr. Elephant能自动化收集所有指标，进行数据分析，并以简单易用的方式进行呈现。Dr. Elephant的目标是提高开发人员的开发效率和增加集群任务调试的高效性。Dr. Elephant支持对Hadoop和Spark任务进行可插拔式、配置化以及基于规则的启发式job性能分析，并且根据分析结果给出合适的建议来指导如何调优使任务更有效率。
 
为什么选择Dr. Elephant？
其它开源或者商用Hadoop优化工具都是收集系统资源指标和监控集群资源信息，关注点仅在于简化Hadoop集群的发布和管理，而很少有工具是来帮助Hadoop优化任务流。这些工具不支持Hadoop集群的规模化和Hadoop框架的增长，而Dr. Elephant支持Hadoop生态的各种框架，并且很容易的扩展到新的框架，已经支持Spark。Dr. Elephant让用户更清晰的掌握Hadoop和Spark原理，并帮助其轻松的优化任务。
 
Dr. Elephant如何工作？
Dr. Elephant从YARN Resource Manager周期性获取所有最近运行成功和失败的应用列表，然后从Job History Server中攫取每个应用的元数据，包括job counters、任务配置和任务数据。有了元数据后，Dr. Elephant进行启发式分析，并生成每个任务的诊断报告，从而进行相应的整体优化。Dr. Elephant将会标记出五个等级问题严重性，指出潜在的性能问题。

图1 Dr. Elephant问题等级

图2 Dr. Elephant的面板
 
通过Dr. Elephant的UI查看数据面板，见图2，这里显示集群的相关统计信息，包括集群上运行的任务数，需要优化的任务数，以及基于启发式分析发现的严重任务数。图中是最近24小时的Dr. Elephant分析的所有最近的任务。

图3 Dr. Elephant的搜索页
 
Dr. Elephant提供一个搜索功能，帮助用户通过任务ID/应用ID，执行ID，任务类型，任务严重程度和任务完成时间等来搜索任务。

图4 Dr. Elephant任务页面
 
当你点击指定的搜索结果，会显示完整的任务信息，并能查看相互引用的任务流。

图5 Dr. Elephant的工作流历史

图6 Dr. Elephant的任务历史
 
Dr. Elephant的任务历史和工作流历史可以帮用户比较前后执行的区别。Dr. Elephant通过启发式计算出每个任务执行的性能得分并作图。这个图表可以帮助用户很直观的分析哪个性能好。
 
家庭医生
Dr. Elephant在LinkedIn非常受欢迎，大家钟爱其简洁性。Dr. Elephant通过简单的诊断可以解决百分之八十的问题。Dr. Elephant提供任务级别的建议帮助用户去理解和优化Hadoop工作流。

Dr. Elephant已经完全和Hadoop生态整合。在LinkedIn，开发人员使用Dr. Elephant作为开发流程的一部分，线上任务强制达到绿色级别。

分享阅读中文原文：https://www.infoq.com/cn/news/2016/04/Dr-Elephant-LinkedIn
分享于都英文原文：https://engineering.linkedin.com/blog/2016/04/dr-elephant-open-source-self-serve-performance-tuning-hadoop-spark