Category Archives: Backend

使用cloudflare加速你的网站隐藏你的网站IP

前言 cloudflare 是一家国外的 CDN 加速服务商，还是很有名气的。提供免费和付费的加速和网站保护服务。以前推荐过的百度云加速的国外节点就是和 cloudflare 合作使用的 cloudflare 的节点。 cloudflare 提供了不同类型的套餐，即使是免费用户，cloudflare 提供的功能也是很全面的。 对于访客来自于国外的网站很不错；对于访客来自于国内的网站加速效果有限，有些甚至会变慢，不过其安全防护功能也很不错。 添加网站 官网： www.cloudflare.com 使用邮箱注册，注册完后自动进入添加网站界面。 添加网站分为四步：添加网站域名、添加DNS记录、选择方案、更新域名服务器。 Paste_Image.png 1.添加网站 填入自己的主域名（不带 www 的），“Scan DNS Records”。 2.添加DNS记录 添加完成后会自动扫描 DNS 记录，等待完成，“Continue”。 下面会列出所有扫描到的 DNS 记录。黄色云朵表示该解析通过 CDN 访问，灰色云朵表示不通过 CDN 访问，点击云朵可以切换状态。 这里建议全部调为黄色云朵走 CDN 访问，隐藏网站真实 IP 地址。全站通过 CDN 访问可以有效防止网站真实IP泄漏，保护原站安全。 记录简单的话可以直接按默认条目；如果没有扫描出来原记录或要手动添加，建议至少添加 @ 和 www 两条指向原网站 IP 的 A 记录，TTL 默认。 Paste_Image.png 3.选择方案 选择适合自己的方案，一般小站博客免费方案就够了。当然，有更高需求的可按需选择付费方案。 Paste_Image.png 4.更新域名服务器 右侧是新的域名服务器。进入域名管理面板，更改域名服务器为新的。 Paste_Image.png 域名服务器更改成功后会收到邮件提示。“Continue”，完成。 Paste_Image.png from：https://www.jianshu.com/p/95a8f8e28649 最后成功以后，你 ping 你的域名 则发现其返回的IP地址已经不是真实IP了！例如：

  摘录自：http://www.freebuf.com/articles/web/41533.html 大部分通过CloudFlare保护的网站都有一个direct-xxx（xxx对应网站域名）的子站，通过这个子站我们可以获得该网站的真是IP。例如这里我随便找个网站，我们手工测试一下： 我们不做DDOS，没必要去较真网站的真实IP是什么，但如果渗透过程中需要从Web入手，而暂时又找不到可利用的漏洞，需要通过其他弱智的方式来进行入侵，如各种C段的渗透等，那样真实的网站IP就显得比较重要了。OK，先ping一下，看看, 141.101.122.201，美国。 试试刚才说的那个方法 蛋疼了，被CloudFlare隐藏的那是相当的深了，这果然是特殊照顾的客户啊。这里就不得不祭出神站了，提到一个比较叼的网站，www.crimeflare.com，网站有个DomainSearchBox，可以对CloudFlare客户网站进行真实IP查询。这个估计是哪个哥们跟CloudFlare网站过不去建立的吧。 果断发现真实IP，147开头，香港大学的，具体地址就不透露了，免得顺丰快递上门服务。如何验证真实性呢，最简单的办法就是修改本地的Host文件，真实的IP对应与之对应的域名即可。但是验证了一下，发现不对，这只是曾经用过的一台服务器IP地址，应该是这鸟网站扛不住的时候CF帮忙搬家了，这里只能呵呵一下。看了下C段，全是香港大学的机器，没啥兴趣，搞来意义不大，就不浪费时间了。然后各种抓包分析，后来还是没突破，最终拿到了个CDN的小工具，类似于核总写的CDN终结者一样吧（某大牛，具体名字就不方便透露了），配和工具倒腾了会，竟然还真让我找到了一个在美国的IP地址（54.xxx.xxx.xx），查一下地址看看。 验证后果然为真实服务器，果然是AWS地址上，也验证了之前所有的想法，原来躲在了在亚马逊云上面，又是用的EC2产品，对ec2不太了解，注册了个aws看了看，对于EC2这种产品没有0Day是基本直接渗透没希望的。   from: https://www.cnblogs.com/bonelee/p/8670660.html

nginx 优化(突破十万并发)

一般来说nginx 配置文件中对优化比较有作用的为以下几项： worker_processes 8; nginx 进程数，建议按照cpu 数目来指定，一般为它的倍数。 worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000; 为每个进程分配cpu，上例中将8 个进程分配到8 个cpu，当然可以写多个，或者将一 个进程分配到多个cpu。 worker_rlimit_nofile 102400; 这个指令是指当一个nginx 进程打开的最多文件描述符数目，理论值应该是最多打开文 件数（ulimit -n）与nginx 进程数相除，但是nginx 分配请求并不是那么均匀，所以最好与ulimit -n 的值保持一致。 use epoll; 使用epoll 的I/O 模型 worker_connections 102400; 每个进程允许的最多连接数， 理论上每台nginx 服务器的最大连接数为worker_processes*worker_connections。 keepalive_timeout 60; keepalive 超时时间。 client_header_buffer_size 4k; 客户端请求头部的缓冲区大小，这个可以根据你的系统分页大小来设置，一般一个请求 头的大小不会超过1k，不过由于一般系统分页都要大于1k，所以这里设置为分页大小。分页大小可以用命令getconf PAGESIZE 取得。 open_file_cache max=102400 inactive=20s; 这个将为打开文件指定缓存，默认是没有启用的，max 指定缓存数量，建议和打开文件数一致，inactive 是指经过多长时间文件没被请求后删除缓存。 open_file_cache_valid 30s; 这个是指多长时间检查一次缓存的有效信息。 open_file_cache_min_uses 1; open_file_cache 指令中的inactive 参数时间内文件的最少使用次数，如果超过这个数字，文件描述符一直是在缓存中打开的，如上例，如果有一个文件在inactive 时间内一次没被使用，它将被移除。 关于内核参数的优化： net.ipv4.tcp_max_tw_buckets = 6000 timewait 的数量，默认是180000。 net.ipv4.ip_local_port_range = 1024 65000 允许系统打开的端口范围。 net.ipv4.tcp_tw_recycle = 1 启用timewait 快速回收。 net.ipv4.tcp_tw_reuse = 1 开启重用。允许将TIME-WAIT sockets 重新用于新的TCP 连接。 […]

PHP函数内访问全局变量

$stringVarGlo="global variant";//全局变量   textGlobalVariant1(); //方法一使用$GLOBALS["全局变量名"] echo $stringVarGlo,"<br/>";   textGlobalVariant2();  //方法二使用global 变量名声明引入; echo $stringVarGlo,"<br/>";   function textGlobalVariant1(){ $varGlob="textGlobalVariant1"; $GLOBALS["stringVarGlo"].=$varGlob;           //使用$GLOBALS["全局变量名"] }   function textGlobalVariant2(){ global    $stringVarGlo; //使用global 变量名声明引入; $varGlob="textGlobalVariant2"; $stringVarGlo.=$varGlob; }   输出 global varianttextGlobalVariant1 global varianttextGlobalVariant1textGlobalVariant2 ——————— 作者：岁月绵长 来源：CSDN 原文：https://blog.csdn.net/s1e1s/article/details/46833307 版权声明：本文为博主原创文章，转载请附上博文链接！

RabbitMQ消息持久化

目录 一、前言 二、队列持久化 　　2.1 查看存在的队列和消息数量 　　2.2 持久化队列 三、消息持久化 四、总结 一、前言 如果我们希望即使在RabbitMQ服务重启的情况下，也不会丢失消息，我们可以将Queue与Message都设置为可持久化的（durable），这样可以保证绝大部分情况下我们的RabbitMQ消息不会丢失。当然还是会有一些小概率事件会导致消息丢失。 二、队列持久化 　　2.1 查看存在的队列和消息数量 在windows环境下，在rabbitmq的安装目录/sbin下，通过rabbitmqctl.bat list_queues查看　 这边启动了两个producer,分别生成两个队列hello 和 hello1,并且他们都有一个消息存在 重启rabbitmq，模拟故障 可以看到重启后两个队列都消失了 　　2.2 持久化队列 我们就hello队列持久化 在声明队列名称时，持久化队列，生产端和消费端都要 1 channel.queue_declare(queue=’hello', durable=True) 我们重复上面的操作，但是给hello队列做持久化，而hello1不做，并重启rabbitmq 可以看到重启后，hello队列还在，hello1队列消失了，但是原本hello中的一条消息也没有保存下来。所以在这边我们仅仅做到了消息队列的持久化，还没有做消息持久化。 三、消息持久化 我们刚才实现了在rabbitmq崩溃的情况下，就队列本身保存下来，重启后队列还在。接下来我们要将消息也保存下来，即消息的持久化 1 2 3 4 5 6 7 8 9 channel.basic_publish(exchange=",                       routing_key=’hello',                       body=’hello',                       properties=pika.BasicProperties(                           delivery_mode=2,  # make message persistent                       )) # 增加properties，这个properties 就是消费端 callback函数中的properties # delivery_mode = 2  持久化消息 生产端生成一个消息，并重启rabbitmq 可以看到，经过队列和消息持久化后的hello, 在重启的情况下，队列和消息都存在，没有消失。 消费端再重启后也能正常接收 四、总结 队列持久化需要在声明队列时添加参数 durable=True，这样在rabbitmq崩溃时也能保存队列 仅仅使用durable=True ，只能持久化队列，不能持久化消息 消息持久化需要在消息生成时，添加参数 properties=pika.BasicProperties(delivery_mode=2)   from: https://www.cnblogs.com/bigberg/p/8195622.html#_label3

Elasticsearch－基础介绍及索引原理分析

最近在参与一个基于Elasticsearch作为底层数据框架提供大数据量(亿级)的实时统计查询的方案设计工作，花了些时间学习Elasticsearch的基础理论知识，整理了一下，希望能对Elasticsearch感兴趣/想了解的同学有所帮助。 同时也希望有发现内容不正确或者有疑问的地方，望指明，一起探讨，学习，进步。 介绍 Elasticsearch 是一个分布式可扩展的实时搜索和分析引擎,一个建立在全文搜索引擎 Apache Lucene(TM) 基础上的搜索引擎.当然 Elasticsearch 并不仅仅是 Lucene 那么简单，它不仅包括了全文搜索功能，还可以进行以下工作: 分布式实时文件存储，并将每一个字段都编入索引，使其可以被搜索。 实时分析的分布式搜索引擎。 可以扩展到上百台服务器，处理PB级别的结构化或非结构化数据。 基本概念 先说Elasticsearch的文件存储，Elasticsearch是面向文档型数据库，一条数据在这里就是一个文档，用JSON作为文档序列化的格式，比如下面这条用户数据：

  用Mysql这样的数据库存储就会容易想到建立一张User表，有balabala的字段等，在Elasticsearch里这就是一个文档，当然这个文档会属于一个User的类型，各种各样的类型存在于一个索引当中。这里有一份简易的将Elasticsearch和关系型数据术语对照表:

  一个 Elasticsearch 集群可以包含多个索引(数据库)，也就是说其中包含了很多类型(表)。这些类型中包含了很多的文档(行)，然后每个文档中又包含了很多的字段(列)。Elasticsearch的交互，可以使用Java API，也可以直接使用HTTP的Restful API方式，比如我们打算插入一条记录，可以简单发送一个HTTP的请求：

  更新，查询也是类似这样的操作，具体操作手册可以参见Elasticsearch权威指南 索引 Elasticsearch最关键的就是提供强大的索引能力了，其实InfoQ的这篇时间序列数据库的秘密(2)——索引写的非常好，我这里也是围绕这篇结合自己的理解进一步梳理下，也希望可以帮助大家更好的理解这篇文章。 Elasticsearch索引的精髓： 一切设计都是为了提高搜索的性能 另一层意思：为了提高搜索的性能，难免会牺牲某些其他方面，比如插入/更新，否则其他数据库不用混了。前面看到往Elasticsearch里插入一条记录，其实就是直接PUT一个json的对象，这个对象有多个fields，比如上面例子中的name, sex, age, about, interests，那么在插入这些数据到Elasticsearch的同时，Elasticsearch还默默1的为这些字段建立索引--倒排索引，因为Elasticsearch最核心功能是搜索。 Elasticsearch是如何做到快速索引的 InfoQ那篇文章里说Elasticsearch使用的倒排索引比关系型数据库的B-Tree索引快，为什么呢？ 什么是B-Tree索引? 上大学读书时老师教过我们，二叉树查找效率是logN，同时插入新的节点不必移动全部节点，所以用树型结构存储索引，能同时兼顾插入和查询的性能。因此在这个基础上，再结合磁盘的读取特性(顺序读/随机读)，传统关系型数据库采用了B-Tree/B+Tree这样的数据结构： 为了提高查询的效率，减少磁盘寻道次数，将多个值作为一个数组通过连续区间存放，一次寻道读取多个数据，同时也降低树的高度。 什么是倒排索引? 继续上面的例子，假设有这么几条数据(为了简单，去掉about, interests这两个field):

  ID是Elasticsearch自建的文档id，那么Elasticsearch建立的索引如下: Name:

  Age:

  Sex:

  Posting List Elasticsearch分别为每个field都建立了一个倒排索引，Kate, John, 24, Female这些叫term，而[1,2]就是Posting List。Posting list就是一个int的数组，存储了所有符合某个term的文档id。 看到这里，不要认为就结束了，精彩的部分才刚开始… 通过posting list这种索引方式似乎可以很快进行查找，比如要找age=24的同学，爱回答问题的小明马上就举手回答：我知道，id是1，2的同学。但是，如果这里有上千万的记录呢？如果是想通过name来查找呢？ Term Dictionary Elasticsearch为了能快速找到某个term，将所有的term排个序，二分法查找term，logN的查找效率，就像通过字典查找一样，这就是Term Dictionary。现在再看起来，似乎和传统数据库通过B-Tree的方式类似啊，为什么说比B-Tree的查询快呢？ Term Index B-Tree通过减少磁盘寻道次数来提高查询性能，Elasticsearch也是采用同样的思路，直接通过内存查找term，不读磁盘，但是如果term太多，term dictionary也会很大，放内存不现实，于是有了Term Index，就像字典里的索引页一样，A开头的有哪些term，分别在哪页，可以理解term index是一颗树： 这棵树不会包含所有的term，它包含的是term的一些前缀。通过term index可以快速地定位到term dictionary的某个offset，然后从这个位置再往后顺序查找。 所以term index不需要存下所有的term，而仅仅是他们的一些前缀与Term Dictionary的block之间的映射关系，再结合FST(Finite State Transducers)的压缩技术，可以使term […]

官网生成带Zero的Abp出现Default language is not defined!的错误

官网生成的ABP + module zero出现Default language is not defined!的错误，原因是数据库没有language数据，而不是缺少language.xml资源文件，所以先创建数据库就好了。   解决方法： 1.选择Web项目作为起始项目。 2.打开程序包管理控制台，选择“EntityFramework”项目作为默认项目，然后运行EF的’Update-Database’命令。该命令会创建数据库。 3.运行该应用，默认的用户名是’admin’，密码是’123qwe’。 在执行第2步时遇到了如下错误： Update-Database : 无法将“Update-Database”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。请检查名称的拼写，如果包括路径，请确保路径正确，然后重试。 原因可能是EntityFramework没有安装，Install-Package EntityFramework就好了。什么？还是不行？全部重新生成再重新打开vs试试吧！   参考：Module-Zero之启动模板   from: https://blog.csdn.net/klo220/article/details/51138582

基于DDD的现代ASP.NET开发框架--ABP系列之2、ABP入门教程

ABP是“ASP.NET Boilerplate Project (ASP.NET样板项目)”的简称。 ASP.NET Boilerplate是一个用最佳实践和流行技术开发现代WEB应用程序的新起点，它旨在成为一个通用的WEB应用程序框架和项目模板。 ABP的官方网站：http://www.aspnetboilerplate.com ABP在Github上的开源项目：https://github.com/aspnetboilerplate   ABP 的由来 “DRY——避免重复代码”是一个优秀的开发者在开发软件时所具备的最重要的思想之一。我们在开发企业WEB应用程序时都有一些类似的需求，例如：都需要登录页面、用户/角色管理、权限验证、数据有效性验证、多语言/本地化等等。一个高品质的大型软件都会运用一些最佳实践，例如分层体系结构、领域驱动设计、依赖注入等。我们也可能会采用ORM、数据库迁移（Database Migrations）、日志记录（Logging）等工具。 从零开始创建一个企业应用程序是一件繁琐的事，因为需要重复做很多常见的基础工作。许多公司都在开发自己的应用程序框架来重用于不同的项目，然后在框架的基础上开发一些新的功能。但并不是每个公司都有这样的实力。假如我们可以分享的更多，也许可以避免每个公司或每个项目的重复编写类似的代码。作者之所以把项目命名为“ASP.NET Boilerplate”，就是希望它能成为开发一般企业WEB应用的新起点，直接把ABP作为项目模板。   ABP是什么？ ABP是为新的现代Web应用程序使用最佳实践和使用最流行工具的一个起点。可作为一般用途的应用程序的基础框架或项目模板。它的功能包括： 服务器端： 基于最新的.NET技术 （目前是ASP.NET MVC 5、Web API 2、C# 5.0，在ASP.NET 5正式发布后会升级） 实现领域驱动设计（实体、仓储、领域服务、领域事件、应用服务、数据传输对象，工作单元等等） 实现分层体系结构（领域层，应用层，展现层和基础设施层） 提供了一个基础架构来开发可重用可配置的模块 集成一些最流行的开源框架/库，也许有些是你正在使用的。 提供了一个基础架构让我们很方便地使用依赖注入（使用Castle Windsor作为依赖注入的容器） 提供Repository仓储模式支持不同的ORM（已实现Entity Framework 、NHibernate、MangoDb和内存数据库） 支持并实现数据库迁移（EF 的 Code first） 模块化开发（每个模块有独立的EF DbContext，可单独指定数据库） 包括一个简单的和灵活的多语言/本地化系统 包括一个 EventBus来实现服务器端全局的领域事件 统一的异常处理（应用层几乎不需要处理自己写异常处理代码） 数据有效性验证（Asp.NET MVC只能做到Action方法的参数验证，ABP实现了Application层方法的参数有效性验证） 通过Application Services自动创建Web Api层（不需要写ApiController层了） 提供基类和帮助类让我们方便地实现一些常见的任务 使用“约定优于配置原则”   客户端： Bootstrap、Less、AngularJs、jQuery、Modernizr和其他JS库: jQuery.validate、jQuery.form、jQuery.blockUI、json2等 为单页面应用程序（AngularJs、Durandaljs）和多页面应用程序（Bootstrap+Jquery）提供了项目模板。 自动创建Javascript 的代理层来更方便使用Web Api 封装一些Javascript 函数，更方便地使用ajax、消息框、通知组件、忙状态的遮罩层等等   除ABP框架项目以外，还开发了名叫“Zero”的模块，实现了以下功能： 身份验证与授权管理（通过ASP.NET Identity实现的） 用户&角色管理 系统设置存取管理（系统级、租户级、用户级，作用范围自动管理） 审计日志（自动记录每一次接口的调用者和参数）   ABP不是什么？ ABP 提供了一个应用程序开发模型用于最佳实践。它拥有基础类、接口和工具使我们容易建立起可维护的大规模的应用程序。 然而： 它不是RAD工具之一，RAD工具的目的是无需编码创建应用程序。相反，ABP提供了一种编码的最佳实践。 它不是一个代码生成工具。在运行时虽然它有一些特性构建动态代码，但它不能生成代码。 它不是一个一体化的框架。相反，它使用流行的工具/库来完成特定的任务（例如用EF做ORM，用Log4Net做日志记录，使得Castle Windsor作为赖注入容器， AngularJs 用于SPA 框架）。   就我使用了ABP几个月的经验来看，虽然ABP不是RAD，但是用它开发项目绝对比传统三层架构要快很多。 虽然ABP不是代码生成工具，但因为有了它，使我们项目的代码更简洁规范，这有利于使用代码生成工具。 我自己使用VS2013的Scaffolder+T4开发的代码生成器，可根据领域对象的UML类图自动生成全部前后端代码和数据库，简单的CURD模块几乎不需要编写代码，有复杂业务逻辑的模块主要补充领域层代码即可。这样就能把时间多花在领域模型的设计上，减少写代码的时间。   下面通过原作者的“简单任务系统”例子，演示如何运用ABP开发项目 从模板创建空的web应用程序 […]

Nginx、HAProxy、LVS三者的优缺点

一、Nginx优点： 1、工作在网络7层之上，可针对http应用做一些分流的策略，如针对域名、目录结构，它的正规规则比HAProxy更为强大和灵活，所以，目前为止广泛流行。 2、Nginx对网络稳定性的依赖非常小，理论上能ping通就能进行负载功能。 3、Nginx安装与配置比较简单，测试也比较方便，基本能把错误日志打印出来。 4、可以承担高负载压力且稳定，硬件不差的情况下一般能支撑几万次的并发量，负载度比LVS小。 5、Nginx可以通过端口检测到服务器内部的故障，如根据服务器处理网页返回的状态码、超时等，并会把返回错误的请求重新提交到另一个节点。 6、不仅仅是优秀的负载均衡器/反向代理软件，同时也是强大的Web应用服务器。LNMP也是近些年非常流行的Web架构，在高流量环境中稳定性也很好。 7、可作为中层反向代理使用。 8、可作为静态网页和图片服务器。 9、Nginx社区活跃，第三方模块非常多，相关的资料在网上比比皆是。 Nginx常规的和HTTP请求和相应流程图： Nginx缺点： 1、适应范围较小，仅能支持http、https、Email协议。 2、对后端服务器的健康检查，只支持通过端口检测，不支持url来检测。比如用户正在上传一个文件，而处理该上传的节点刚好在上传过程中出现故障，Nginx会把上传切到另一台服务器重新处理，而LVS就直接断掉了，如果是上传一个很大的文件或者很重要的文件的话，用户可能会因此而不满。   二、LVS优点： 1、抗负载能力强、是工作在网络4层之上仅作分发之用，没有流量的产生，这个特点也决定了它在负载均衡软件里的性能最强的，对内存和cpu资源消耗比较低。 2、配置性比较低，这是一个缺点也是一个优点，因为没有可太多配置的东西，所以并不需要太多接触，大大减少了人为出错的几率。 3、工作稳定，因为其本身抗负载能力很强，自身有完整的双机热备方案，如LVS+Keepalived，不过我们在项目实施中用得最多的还是LVS/DR+Keepalived。 4、无流量，LVS只分发请求，而流量并不从它本身出去，这点保证了均衡器IO的性能不会收到大流量的影响。 5、应用范围比较广，因为LVS工作在4层，所以它几乎可以对所有应用做负载均衡，包括http、数据库、在线聊天室等等。 LVS DR(Direct Routing)模式的网络流程图： LVS的缺点： 1、软件本身不支持正则表达式处理，不能做动静分离；而现在许多网站在这方面都有较强的需求，这个是Nginx/HAProxy+Keepalived的优势所在。 2、如果是网站应用比较庞大的话，LVS/DR+Keepalived实施起来就比较复杂了，特别后面有Windows Server的机器的话，如果实施及配置还有维护过程就比较复杂了，相对而言，Nginx/HAProxy+Keepalived就简单多了。   三、HAProxy优点： 1、HAProxy是支持虚拟主机的，可以工作在4、7层(支持多网段) 2、HAProxy的优点能够补充Nginx的一些缺点，比如支持Session的保持，Cookie的引导；同时支持通过获取指定的url来检测后端服务器的状态。 3、HAProxy跟LVS类似，本身就只是一款负载均衡软件；单纯从效率上来讲HAProxy会比Nginx有更出色的负载均衡速度，在并发处理上也是优于Nginx的。 4、HAProxy支持TCP协议的负载均衡转发，可以对MySQL读进行负载均衡，对后端的MySQL节点进行检测和负载均衡，大家可以用LVS+Keepalived对MySQL主从做负载均衡。 5、HAProxy负载均衡策略非常多，HAProxy的负载均衡算法现在具体有如下8种 ①　roundrobin 表示简单的轮询，每个服务器根据权重轮流使用，在服务器的处理时间平均分配的情况下这是最流畅和公平的算法。该算法是动态的，对于实例启动慢的服务器权重会在运行中调整。最大支持4095个后端主机； ②　leastconn 连接数最少的服务器优先接收连接。leastconn建议用于长会话服务，例如LDAP、SQL、TSE等，而不适合短会话协议。如HTTP.该算法是动态的，对于实例启动慢的服务器权重会在运行中调整。 ③　static-rr 每个服务器根据权重轮流使用，类似roundrobin，但它是静态的，意味着运行时修改权限是无效的。另外，它对服务器的数量没有限制。该算法一般不用； ④　source 对请求源IP地址进行哈希，用可用服务器的权重总数除以哈希值，根据结果进行分配。只要服务器正常，同一个客户端IP地址总是访问同一个服务器。如果哈希的结果随可用服务器数量而变化，那么客户端会定向到不同的服务器；该算法一般用于不能插入cookie的Tcp模式。它还可以用于广域网上为拒绝使用会话cookie的客户端提供最有效的粘连；该算法默认是静态的，所以运行时修改服务器的权重是无效的，但是算法会根据“hash-type”的变化做调整。 ⑤　uri 表示根据请求的URI左端（问号之前）进行哈希，用可用服务器的权重总数除以哈希值，根据结果进行分配。只要服务器正常，同一个URI地址总是访问同一个服务器。一般用于代理缓存和反病毒代理，以最大限度的提高缓存的命中率。该算法只能用于HTTP后端；该算法一般用于后端是缓存服务器；该算法默认是静态的，所以运行时修改服务器的权重是无效的，但是算法会根据“hash-type”的变化做调整。 ⑥　url_param 在HTTP GET请求的查询串中查找<param>中指定的URL参数，基本上可以锁定使用特制的URL到特定的负载均衡器节点的要求；该算法一般用于将同一个用户的信息发送到同一个后端服务器；该算法默认是静态的，所以运行时修改服务器的权重是无效的，但是算法会根据“hash-type”的变化做调整。 ⑦　hdr(name) 在每个HTTP请求中查找HTTP头<name>，HTTP头<name>将被看作在每个HTTP请求，并针对特定的节点；如果缺少头或者头没有任何值，则用roundrobin代替；该算法默认是静态的，所以运行时修改服务器的权重是无效的，但是算法会根据“hash-type”的变化做调整。 ⑧　rdp-cookie（name） 为每个进来的TCP请求查询并哈希RDP cookie<name>；该机制用于退化的持久模式，可以使同一个用户或者同一个会话ID总是发送给同一台服务器。如果没有cookie，则使用roundrobin算法代替；该算法默认是静态的，所以运行时修改服务器的权重是无效的，但是算法会根据“hash-type”的变化做调整。 haproxy的工作模型图： HAPorxy缺点： 1. 不支持POP/SMTP协议 2. 不支持SPDY协议 3. 不支持HTTP cache功能。现在不少开源的lb项目，都或多或少具备HTTP cache功能。 4. 重载配置的功能需要重启进程，虽然也是soft restart，但没有Nginx的reaload更为平滑和友好。 5. 多进程模式支持不够好 ——————— 作者：qi_li_juan 来源：CSDN 原文：https://blog.csdn.net/qlj324513/article/details/81541282 版权声明：本文为博主原创文章，转载请附上博文链接！

nginx实现请求的负载均衡 + keepalived实现nginx的高可用

前言 使用集群是网站解决高并发、海量数据问题的常用手段。当一台服务器的处理能力、存储空间不足时，不要企图去换更强大的服务器，对大型网站而言，不管多么强大的服务器，都满足不了网站持续增长的业务需求。这种情况下，更恰当的做法是增加一台服务器分担原有服务器的访问及存储压力。通过负载均衡调度服务器，将来自浏览器的访问请求分发到应用服务器集群中的任何一台服务器上，如果有更多的用户，就在集群中加入更多的应用服务器，使应用服务器的负载压力不再成为整个网站的瓶颈。 摘自《大型网站技术架构_核心原理与案例分析》 另外，大家可以看我的这两篇博客：LVS + keepalived + nginx + tomcat 实现主从热备 + 负载均衡 和 主从热备+负载均衡（LVS + keepalived），对比下这三篇博客，其中区别及各自的优缺点需要大家好好体会。 环境准备 192.168.0.221：nginx + keepalived   master 192.168.0.222：nginx + keepalived   backup 192.168.0.223：tomcat 192.168.0.224：tomcat 虚拟ip(VIP):192.168.0.200，对外提供服务的ip，也可称作浮动ip 各个组件之间的关系图如下： tomcat做应用服务器 tomcat的安装不在本博客范围之内，具体可参考virtualBox安装centos，并搭建tomcat，tomcat的webapps下记得放自己的应用，我的是myWeb，如果大家也用我的myWeb，那么index.jsp中的ip需要换成自己的 将192.168.0.223、192.168.0.224上的tomcat启动起来，tomcat的路径可能和我的不一致，需要写成自己的 # cd /usr/local/tomcat7/bin # ./startup.sh 访问myWeb如下 nginx做负载均衡 nginx的安装，本文就不讲述了，具体可参考LVS + keepalived + nginx + tomcat 实现主从热备 + 负载均衡 nginx.conf内容如下

主从nginx的配置文件完全一样，nginx.conf配置可复杂可简单，大家根据自己的情况自行配置，照搬上述配置也是可以的。 配置好后，启动nginx，路径要写自己的 # cd /usr/local/nginx/sbin # ./nginx 访问nginx，效果如下： 两台nginx服务器服务正常，此时是没有主从之分的，两者级别一样高，当配置keepalived之后就有了主从之分了。 keepalived实现nginx高可用(HA) keepalived的安装本文就不讲述了，具体可参考主从热备+负载均衡（LVS + keepalived） keepalived作用其实在第一张图中已经有所体现，主要起到两个作用：实现VIP到本地ip的映射； 以及检测nginx状态。 master上的keepalived.conf内容如下：

backup上的keepalived.conf内容如下：

nginx检测脚本check_nginx_pid.sh内容如下：

启动keepalived # service keepalived start 访问VIP，效果如下： 我们来看下keepalived的日志信息 master（192.168.0.221）： backup（192.168.0.222）： 当我们把master上的keepalived停掉（模拟宕机），再来看下keepalived日志 原master（192.168.0.221）： 原backup（192.168.0.222）： 通过VIP可以正常访问服务，前端请求感受不到后端nginx的切换；重新唤醒原master（192.168.0.221）的测试这里就不进行了，大家自行测试 注意点 1、执行脚本时报错：/bin/sh^M: bad […]

keepalived实现双机热备

keepalived的作用是检测后端TCP服务的状态，如果有一台提供TCP服务的后端节点死机，或者工作出现故障，keepalived会及时检测到，并将有故障的节点从系统中剔除，当提供TCP服务的节点恢复并且正常提供服务后keepalived会自动将TCP服务的节点加入到集群中。这些工作都是keepalived自动完成，不需要人工干涉，需要人工做的只是修复发生故障的服务器，以下通过示例来演示。 前提：为了测试能顺利进行，需先关闭selinux和firewalld。 测试环境如下： 1 2 3 4 5 keepalived主机：　10.0.0.20 keepalived备机：　10.0.0.21 http服务器1：　　　10.0.0.22 http服务器2：　　　10.0.0.23 VIP : 　　　　　　10.0.0.100   一、两台http服务器的安装 1、  两台机均安装httpd 1 $ sudo yum install -y httpd   2、  添加首页 1 2 3 4 5 6 7 $ sudo -i #http服务器1设置 # echo “10.0.0.22” >/var/www/html/index.html #http服务器2设置 # echo “10.0.0.23” >/var/www/html/index.html   3、  启动并设置开机启动httpd 1 2 $ sudo systemctl start httpd $ sudo systemctl enable httpd   二、两台keepalived主机的设置 1、  两台机均安装keepalived 1 2 3 #安装依赖文件与keepalive $ sudo yum install -y openssl openssl-devel keepalived   2、  keepalived主机配置   1 2 3 4 […]