节点服务器

之前向大家介绍过全球最大在线图片服务网站 Flickr网站架构 ，Yupoo（又拍网）作为国内最大的图片服务提供商，我们也一起来看看它的架构，同样是提供图片服务，看看他与Flickr的差别在哪里，大家看完本文可以思考一下。 一、先来看看Yupoo网站的基本信息： 带宽：4000M/S ( 参考 ) 服务器数量：60 台左右 Web服务器：Lighttpd, Apache, nginx 应用服务器：Tomcat 其他：Python, Java, MogileFS 、ImageMagick 等 其架构图如下： 原图链接 二、关于 Squid 与 Tomcat Squid 与 Tomcat 似乎在 Web 2.0 站点的架构中较少看到。我首先是对 Squid 有点疑问，对此阿华的解释是"目前暂时还没找到效率比 Squid 高的缓存系统，原来命中率的确很差，后来在 Squid 前又装了层 Lighttpd, 基于 url 做 hash, 同一个图片始终会到同一台 squid 去，所以命中率彻底提高了" 对于应用服务器层的 Tomcat，现在 Yupoo! 技术人员也在逐渐用其他轻量级的东西替代，而 YPWS/YPFS 现在已经用 Python 进行开发了。 名次解释： YPWS--Yupoo Web Server YPWS 是用 Python开发的一个小型 Web 服务器，提供基本的

SQL Server Alwayson概念总结 原地址： https://www.cnblogs.com/chenmh/p/6972007.html 一、alwayson概念 “可用性组” 针对一组离散的用户数据库（称为“可用性数据库” ，它们共同实现故障转移）支持故障转移环境。 一个可用性组支持一组主数据库以及一至八组对应的辅助数据库(包括一个主副本和两个同步提交辅助副本)。 辅助数据库不是备份，应继续定期备份您的数据库及其事务日志。 每组可用性数据库都由一个“可用性副本” 承载。 有两种类型的可用性副本：一个“主副本” 和一到四个“辅助副本”。 它承载主数据库和一至八个“辅助副本” ，其中每个副本承载一组辅助数据库，并用作可用性组的潜在故障转移目标。 可用性组在 可用性副本级别 进行故障转移。 可用性副本仅在数据库级别提供冗余 － 针对一个可用性组中的该组数据库。 故障转移不是由诸如因数据文件丢失或事务日志损坏而使数据库成为可疑数据库等数据库问题导致的。 主副本使主数据库可用于客户端的读写连接。 此外，它在称为“数据同步” 的过程中使用，在数据库级别进行同步。 主副本将每个主数据库的事务日志记录发送到每个辅助数据库。 每个次要副本缓存事务日志记录（“硬化”日志），然后将它们应用到相应的辅助数据库。 主数据库与每个连接的辅助数据库独立进行数据同步。 因此

Redis事务 redis中的事务是一组命令的集合，事务中的命令要么全部执行，要么都不执行，Redis 通过 MULTI 、DISCARD 、EXEC 和 WATCH 四个命令来实现事务功能，multi表示事物的开启，exec表示事物的执行，exec执行后返回事务执行的结果，discard表示放弃事务执行，清空事务队列中已有的所有命令并退出队列，watch用于监视给定的键，如果键被其他客户端修改，将不会执行事务。 127.0.0.1:6379> multi OK 127.0.0.1:6379> set key 1 QUEUED 127.0.0.1:6379> get key QUEUED 127.0.0.1:6379> exec 1) OK 2) "1" 127.0.0.1:6379> multi OK 127.0.0.1:6379> set key1 1 QUEUED 127.0.0.1:6379> discard OK 127.0.0.1:6379> get key1 (nil) 这里我在另一个客户端修改了被监视的key，导致在这个客户端事务没有执行 127.0.0.1:6379> set key 1 OK 127.0.0.1:6379> watch key OK 127.0.0.1:6379> multi OK 127.0.0.1:6379> incr key QUEUED

一、MySQL主从原理 1、概念 MySQL 主从复制是指数据可以从一个MySQL数据库服务器主节点复制到一个或多个从节点。MySQL 默认采用异步复制方式，这样从节点不用一直访问主服务器来更新自己的数据，数据的更新可以在远程连接上进行，从节点可以复制主数据库中的所有数据库或者特定的数据库，或者特定的表。 2、MySQL主从复制涉及的三个线程 主节点 binary log dump 线程 ：当从节点连接主节点时，主节点会创建一个log dump 线程，用于发送bin-log的内容。在读取bin-log中的操作时，此线程会对主节点上的bin-log加锁，当读取完成，甚至在发动给从节点之前，锁会被释放。 从节点I/O线程 ：当从节点上执行`start slave`命令之后，从节点会创建一个I/O线程用来连接主节点，请求主库中更新的bin-log。I/O线程接收到主节点binlog dump 进程发来的更新之后，保存在本地relay-log中。 从节点SQL线程 ：SQL线程负责读取relay log中的内容，解析成具体的操作并执行，最终保证主从数据的一致性。 对于每一个主从连接，都需要三个进程来完成。当主节点有多个从节点时，主节点会为每一个当前连接的从节点建一个binary log dump 进程，而每个从节点都有自己的I/O进程，SQL进程

一. 系统模型 数据模型 1. ZNode是Zookeeper中数据的最小单元，每个ZNode上可以保存数据，也可以挂载子节点，因此构成了一个层次化的命名空间，称之为树； 2. Zookeeper中事务是指能改变Zookeeper服务器状态的操作，一般包括数据节点创建于删除，数据节点内容更新和客户端会话创建于失效等； 对于每一个事务请求，都会分配一个全局唯一的事务ID，用ZXID来表示，通常是一个64位数字，从ZXID中可以间接的识别这些请求的全局顺序； 节点特性 1. 节点类型可以分为持久节点PERSISTENT，临时节点EPHEMERAL，顺序节点SEQUENTIAL； 2. 持久节点是指被创建后会一直保存在服务器上，直到有删除操作主动清除这个节点； 3. 临时节点的声明周期和客户端的会话绑定在一起，临时节点不能创建子节点； 4. 顺序节点指创建节点时，Zookeeper会自动为节点名加上一个数字后缀，后缀上线是整型的最大值； 5. 每个数据节点也存储了本身的一些状态信息Stat，包括事务ID，版本信息和子节点个数等； 版本 1. 每个数据节点都具有三种类型的版本信息：version，cversion，aversion； 2. 版本表示数据变更操作的次数，即使变更没有引起数据内容的变化； Watcher 1. 一次性：客户端和服务端注册的Watcher一旦被触发

1，MHA概述 MHA目前在mysql高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是一套优秀的作为mysql高可用性环境下故障切换和主从提升的高可用软件。在mysql故障切换过程中，MHA能做到在0-30秒之内自动完成数据库的故障切换操作，并且在进行故障切换操作的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用，MHA里由两个角色一个是MHA Node（数据节点），另一个是MHA Manager（管理节点）。MHA Manager可以单独部署在一台读立的服务器上管理多个master-slave集群，也可以部署在一台slave节点上。 MHA Node运行在每台mysql服务器上，MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master。整个故障转移过程中对应用程序完全透明。 在MHA自动故障切换过程中，MHA试图从宕机的主服务器上保存二进制日志，最大程度地保证数据的不丢失，但这并不总是可行的。例如，如果主服务器硬件故障或无法通过ssh访问，MHA没法保存二进制日志，只进行故障转移而丢失了最新的数据。使用mysql 5.5的半同步复制

注：mongodb当前版本是3.4.3 1.准备三个虚拟机做服务器 192.168.168.129：27017 192.168.168.130：27017 192.168.168.131：27017 2.在三台服务器上安装mongodb服务 详细请见 linux安装mongodb（设置非root用户和开机启动） 3.修改配置，在mongodb.conf增加replSet配置，然后启动服务即可 三个服务器的mongodb.conf中都需要加入replSet的指定，它们都属于repl1复制集； replSet中的S一定要大写！ 4.初始化复制集 登入任意一台机器的mongodb执行，因为是全新的复制集，所以可以任意进入一台执行；要是一台有数据，则需要在有数据上执行；要多台有数据则不能初始化。 rs.initiate({_id:'repl1',members:[{_id:1,host:'192.168.168.129:27017'}]}) 初始化参数说明： _id：复制集名称（第一个_id） members：复制集服务器列表 _id：服务器的唯一ID（数组里_id） host：服务器主机 我们操作的是192.168.168.129服务器，其中repl1即是复制集名称，和mongodb.conf中保持一致，初始化复制集的第一个服务器将会成为主复制集 通过rs.status(

作者 | 邓青琳（轻零） 阿里巴巴技术专家 导读 ：本文转载自阿里巴巴技术专家邓青琳(轻零)在内部的分享，他从阿里云控制台团队转岗到 ECI 研发团队（Serverless Kubernetes 背后的实现基石），从零开始了解 K8s，并从业务发展的视角整理了 K8s 是如何出现的，又是如何工作的。 前言 2019 年下半年，我做了一次转岗，开始接触到 Kubernetes，虽然对 K8s 的认识还非常的不全面，但是非常想分享一下自己的一些收获，希望通过本文能够帮助大家对 K8s 有一个入门的了解。文中有不对的地方，还请各位老司机们帮助指点纠正。 其实介绍 K8s 的文章，网上一搜一大把，而且 Kubernetes 官方文档也写的非常友好，所以直接上来讲 K8s，我觉得我是远远不如网上的一些文章讲的好的。因此我想换一个角度，通过一个业务发展的故事角度，来讲 K8s 是怎么出现的，它又是如何运作的。 故事开始 随着中国老百姓生活水平的不断提高，家家户户都有了小汽车，小王预计 5 年后，汽车报废业务将会迅速发展，而且国家在 2019 年也出台了新政策 《报废机动车回收管理办法》 ，取消了汽车报废回收的“特种行业”属性，将开放市场化的竞争。 小王觉得这是一个创业的好机会，于是找了几个志同道合的小伙伴开始了创业，决定做一个叫“淘车网”的平台。 故事发展 淘车网一开始是一个 all in

3 月，跳不动了？>>> 作者 | 邓青琳（轻零） 阿里巴巴技术专家 导读 ：本文转载自阿里巴巴技术专家邓青琳(轻零)在内部的分享，他从阿里云控制台团队转岗到 ECI 研发团队（Serverless Kubernetes 背后的实现基石），从零开始了解 K8s，并从业务发展的视角整理了 K8s 是如何出现的，又是如何工作的。 前言 2019 年下半年，我做了一次转岗，开始接触到 Kubernetes，虽然对 K8s 的认识还非常的不全面，但是非常想分享一下自己的一些收获，希望通过本文能够帮助大家对 K8s 有一个入门的了解。文中有不对的地方，还请各位老司机们帮助指点纠正。 其实介绍 K8s 的文章，网上一搜一大把，而且 Kubernetes 官方文档也写的非常友好，所以直接上来讲 K8s，我觉得我是远远不如网上的一些文章讲的好的。因此我想换一个角度，通过一个业务发展的故事角度，来讲 K8s 是怎么出现的，它又是如何运作的。 故事开始 随着中国老百姓生活水平的不断提高，家家户户都有了小汽车，小王预计 5 年后，汽车报废业务将会迅速发展，而且国家在 2019 年也出台了新政策 《报废机动车回收管理办法》 ，取消了汽车报废回收的“特种行业”属性，将开放市场化的竞争。 小王觉得这是一个创业的好机会，于是找了几个志同道合的小伙伴开始了创业，决定做一个叫“淘车网”的平台。 故事发展

一.codis介绍 Codis是一个分布式Redis解决方案,对于上层的应用来说,连接到Codis Proxy和连接原生的RedisServer没有明显的区别,有部分命令不支持 Codis底层会处理请求的转发,不停机的数据迁移等工作,所有后边的一切事情,对于前面的客户端来说是透明的,可以简单的认为后边连接的是一个内存无限大的Redis服务. Codis由四部分组成 Codis-proxy:实现redis协议,由于本身是无状态的,因此可以部署很多个节点 Codis-config :是codis的管理工具,包括添加/删除redis节点添加删除proxy节点,发起数据迁移等操作,自带httpserver,支持管理后台方式管理配置 Codis-server :是codis维护的redis分支,基于2.8.21分支,加入了slot的支持和原子的数据迁移指令; codis-proxy和codis-config只能和这个版本的redis交互才能正常运行 Zookeeper,用于codis集群元数据的存储,维护codis集群节点 二.Codis优缺点 优点 对客户端透明,与codis交互方式和redis本身交互一样 支持在线数据迁移,迁移过程对客户端透明有简单的管理和监控界面 支持高可用,无论是redis数据存储还是代理节点 自动进行数据的均衡分配 最大支持1024个redis实例,存储容量海量