节点服务器

某厂面试归来，发现自己落伍了！>>> BUG调用方法 指令测试验证 为什么选择3.2.100 服务器内外网部署windows是master节点，slave是内网节点，salve局域网不能直接访问外网master节点（master是受保护的双网卡服务器）。 如果要改变版本需要在Windows上安装centos虚拟机，并使用高版本的Redis。 注：尽量统一在Unix系统中安装，windows redis版本更新很慢。 来源： oschina 链接： https://my.oschina.net/boonya/blog/3196644

1.Zookeeper简介 Zookeeper是一个分布式服务框架，以前是Apache Hadoop 的一个子项目，现在是Apache的一个独立顶级项目，它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。有关分布式的相关问题请查阅上篇博客： 分布式系统问题及解决方案 2.设计目标 ZooKeeper简单。ZooKeeper允许分布式进程通过共享的分层名称空间相互协调，该命名空间的组织方式类似于标准文件系统。名称空间由数据寄存器（在ZooKeeper看来，称为znode）组成，它们类似于文件和目录。与设计用于存储的典型文件系统不同，ZooKeeper数据保留在内存中，这意味着ZooKeeper可以实现高吞吐量和低延迟数。 ZooKeeper特性还包括高性能、高可用性、严格有序。ZooKeeper的性能方面意味着它可以在大型的分布式系统中使用。可靠性方面使它不会成为单点故障。严格有序意味着可以在客户端上实现复杂的同步原语。 ZooKeeper可复制。像它协调的分布式进程一样，ZooKeeper本身也可以在称为集合的一组主机上进行复制。组成ZooKeeper服务的服务器都必须彼此了解。它们维护内存中的状态图像，以及持久存储中的事务日志和快照。只要大多数服务器可用，ZooKeeper服务将可用

前言 redis的持久化功能在一定程度上保证了数据的安全性，即便时服务器宕机的情况下，也可以保证数据的丢失非常少，通常，为了避免服务的单点故障，会把数据复制到多个副本放在不同的服务器上，且这些拥有数据副本的服务器可以用于处理客户端的读请求，扩展整体的性能，下面将介绍redis的主从复制。 1，主从复制概述 redis的复制功能是支持多个服务器之间的数据同步。被复制的服务器称为主服务器（master），对服务器进行复制操作的为从服务器（slave），主服务器master可以进行读写操作，当发生写操作的时候自动将数据同步到从服务器，而从服务器一般是只读的，并接收master同步过来的数据，一个master可以有多个slave，而一个slave只能由一个master。 主从复制的过程： 1，从节点执行slaveof命令； 2，从节点只是保存了slavef命令中主节点的信息，并没有立即发起复制； 3，从节点内部的定时任务发现由主节点的信息，开始使用socket连接主节点； 4，连接建立成功后，发送ping命令，希望得到pong命令响应，否则会进行重连； 5，如果主节点设置了权限，那么就需要进行权限验证；如果验证失败，复制终止； 6，权限验证通过后，进行数据同步，这是耗时最长的操作，主节点将把所有的数据全部发送给从节点； 7，当主节点把当前的数据同步给从节点后，便完成了复制的建立流程

前言 redis的持久化功能在一定程度上保证了数据的安全性，即便时服务器宕机的情况下，也可以保证数据的丢失非常少，通常，为了避免服务的单点故障，会把数据复制到多个副本放在不同的服务器上，且这些拥有数据副本的服务器可以用于处理客户端的读请求，扩展整体的性能，下面将介绍redis的主从复制。 1，主从复制概述 redis的复制功能是支持多个服务器之间的数据同步。被复制的服务器称为主服务器（master），对服务器进行复制操作的为从服务器（slave），主服务器master可以进行读写操作，当发生写操作的时候自动将数据同步到从服务器，而从服务器一般是只读的，并接收master同步过来的数据，一个master可以有多个slave，而一个slave只能由一个master。 主从复制的过程： 1，从节点执行slaveof命令； 2，从节点只是保存了slavef命令中主节点的信息，并没有立即发起复制； 3，从节点内部的定时任务发现由主节点的信息，开始使用socket连接主节点； 4，连接建立成功后，发送ping命令，希望得到pong命令响应，否则会进行重连； 5，如果主节点设置了权限，那么就需要进行权限验证；如果验证失败，复制终止； 6，权限验证通过后，进行数据同步，这是耗时最长的操作，主节点将把所有的数据全部发送给从节点； 7，当主节点把当前的数据同步给从节点后，便完成了复制的建立流程

无论传统电信运营商愿意看到与否，以Skype为代表的VoIP软件已经在全球拥有越来越多的拥趸。Skype的工作原理究竟是什么？为什么会掀起如此巨大的波澜？从技术角度看它究竟有哪些优势？电信运营商在VoIP领域下一步该如何发展？ Skype与 P2P 所谓P2P（Peer to Peer），其最本质的含义即“对等”，该技术最早是用于网络中对等节点之间的资源和信息共享的技术，通常人们所知道的是将P2P技术用在文件下载过程 中，即网络上的对等终端在下载共享文件的同时又作为一个“种子”为其他对等终端提供资源和信息。后来，Skype在网络通话业务系统中灵活应用了该技术。 由于冲击了传统通信领域，Skype在引起很多争议的同时也使人耳目一新，可以说，Skype是发展和演进了的P2P应用。目前对于P2P技术还没有规范 的定义，结合其已有的应用，就更广泛的意义而言， P2P技术是指网络中的所有节点都动态参与到路由、信息处理和带宽增强等工作中，而不是单纯依靠服务器来完成这些工作。 Skype是P2P技术演进到混合模式后的典型应用，它结合了集中式和分布式的特点，在网络的边缘节点采用集中式的网络结构，而在超级节点之间采用分布式的网络结构，混合模式的P2P网络模型如图1所示。 从网络模型来看，这种混合模式的P2P是经过多年的发展和演进而来的，严格讲，这已经不是纯粹的对等网络结构了，只能称做发展了的P2P

为什么需要集群？ 1、性能 Redis本身的QPS已经很高了，但是如果在一些并发量非常高的情况下，性能还是会受到影响。这个时候我们希望有更多的Redis服务来完成工作。 2、扩展 第二个是出于存储的考虑。因为Redis所有的数据都放在内存中，如果数据量大，很容易受到硬件的限制。升级硬件收效和成本比太低，所以我们需要有一种横向扩展的方法。 3、可用性 第三个是可用性和安全的问题。如果只有一个Redis服务，一旦服务宕机，那么所有的客户端都无法访问，会对业务造成很大的影响。另一个，如果硬件发生故障，而单机的数据无法恢复的话，带来的影响也是灾难性的。 可用性、数据安全、性能都可以通过搭建多个Reids服务实现。其中有一个是主节点（master），可以有多个从节点(slave)。主从之间通过数据同步，存储完全相同的数据。如果主节点发生故障，则把某个从节点改成主节点，访问新的主节点。 Redis主从复制（replication） 主从复制配置 例如一主多从,100是主节点，在每个slave节点的redis.conf配置文件增加一行 slaveof 192.168.1.100 6379 //在主从切换的时候，这个配置会被重写成： #GeneratedbyCONFIGREWRITE replicaof 192.168.1.100 6379 或者在启动服务时通过参数指定master节点： .

超详细，多图文使用galera cluster搭建mysql集群并介绍wsrep相关参数 介绍galera cluster原理的文章已经有一大堆了，百度几篇看一看就能有相关了解，这里就不赘述了。本文主要侧重实操，因为跟着百度前几页的搭建教程或多或少都有坑，前后配置逻辑矛盾的也有。终于，经过几个通宵的bug修复，反复验证，力求以最简洁的代码，最少的操作量，最直白的逻辑来完成集群的搭建。因为操作过程中，网上对wsrep相关参数的介绍少之又少，所以最后特别写了完整版的参数说明，供搭建成功后，各种测试调试使用，对于这些参数有坑的地方，欢迎在底下留言，供大家参考，谢谢。 对于mysql的集群方案，我之前总结过，详情点击查看， 多图文，详细介绍mysql各个集群方案 一，需求了解 Galera Cluster需要至少三个节点的服务器硬件。 如果群集在单个交换机上运行，请使用三个节点。如果您的群集跨越多个交换机，请使用三个交换机。如果您的群集跨越网络，请使用三个网络。如果您的群集跨越数据中心，请使用三个数据中心。这样可以确保在网络中断的情况下，群集可以维护主组件。 1，硬体需求 对于服务器硬件，每个节点至少需要以下组件： 1 GHz单核CPU； 512 MB RAM； 100 Mbps网络连接； 注意：Galera Cluster可能会由于内存不足而在有限的硬件上运行时偶尔崩溃。为避免这种情况

安装 一、安装jdk 创建java安装目录 [ root@This-Address-Is-Forged-64 opt ] # mkdir /opt/java [ root@This-Address-Is-Forged-64 opt ] # ll total 0 drwxr-xr-x. 3 root root 60 Feb 26 20:18 java 并将下载的jdk-8u181-linux-x64.tar.gz放到/opt/java下面，并解压。 [ root@This-Address-Is-Forged-64 java ] # tar -zxvf jdk-8u181-linux-x64.tar.gz [ root@This-Address-Is-Forged-64 java ] # ll total 181296 drwxr-xr-x. 7 10 143 245 Jul 7 2018 jdk1.8.0_181 -rw-r--r--. 1 root root 185646832 Feb 26 19:53 jdk-8u181-linux-x64.tar.gz 编辑环境变量 [ root@This-Address-Is-Forged-64 java ] # vi /etc/profile export JAVA_HOME = /opt/java/jdk1.8.0_181 export

概述 一致Hash在分布式应用中,是常见的负载均衡方式,多用于资源请求映射分散到具体某一台节点服务器,使得每一台服务器能固定处理部分请求,同时,能较小的减少由于动态增减服务器节点带来请求的失效，保证系统更好对外提供服务。 从问题的发展引入思考 图1.假设现在有200万张图片资源，需要随机的分配到3台服务器 除余法 很多人一下子就想到了除余法,通过给每个图片唯一编号(较少的情况),或者通过hash文件名(假设文件名不重复)得到唯一的数字串,然后除余就能随机存放到服务器。 hash ( 文件名 ) % n 正常情况下这个算法已经基本满足,因为每次除余之后必然会得到0,1,2三个数,分别对应三台服务器,下次需要找回这些图片资源只要按同样的方式hash之后就能在对应服务器找到。 但是当图片资源过多无法满足需要增加一台服务器的时候,因为除数的改变,带来余数的改变,也就是服务器数量的改变,带来存储位置的改变,之前存储的图片资源失去了意义,在缓存服务器中,这会导致大量缓存失效,造成缓存的雪崩,为了解决这些问题,一致性hash应运而生。 揭开一致性Hash神秘面纱 首先了解一下计算一致性hash时采用的方式和步骤： 在一个0~2^32区间的圆环上，计算服务器节点的hash值,。 用同样的方式计算存储数据的hash,并映射到相同的圆上。 然后从数据映射到的位置开始顺时针查找

网友服务器在阿里云上海，有部分北京访客反应访问速度慢，这个如何解决呢？从地域上来说北京和上海都在阿里云节点范围内，互相访问也都挺快的。但是也不排除部分北京宽带速度慢，比如长宽、鹏博士等。那么我们不可能要求访客更换联通、电信宽带，只能从自己服务器这头想办法。 本身上海离北京不是很远，访问的 ping 值并不高，比如你在北京 ping 阿里云上海节点，也就不超过 50ms 的延迟，同样上海 ping 北京节点也是这个数字。那么最好的办法是增加华北 2 北京节点服务器，当然这个成本对于大部分中小网站来说太高了，如果不方便新增主机的话，使用 CDN 加速是一个最佳选择。 简单说一下 CDN 的原理。CDN 就是把服务器的内容通过同步分发的方式，发布到遍布全国的 CDN 服务器上面去，这样全国各地的网友访问你网站的时候，CDN 网络可以安排访问距离最近的服务器，等于降低了访问延迟，提高了访客体验。 CDN 加速有免费和付费两种，差别在于可使用的 CDN 加速服务器节点数量不同，免费的流量有一定限制，付费的流量较多，涉及到 https 流量有免费的也有又拍云那种收费的，而类似百度云加速收费版还带有额外的 SEO 优化功能等等。 一般来说免费 CDN 加速流量已经足够用了，而阿里云 CDN 流量搞活动的时候也是超级便宜，国内流量包 100G/年/20 元（http 流量），如果你的网站使用了