关于云上负载均衡的使用

对于http负载均衡，往往有超时限制；对于tcp负载均衡，往往不做源地址转换（无法通过配置的方式设置为需要源地址转换），对于如下部署方式：

APP如果调用自己的话，可能服务器A发起请求，经过负载均衡后，又落到了服务器A自身，这是，由于负载均衡没有做源地址转换，所以，A的回包是发现目的地址就是自己，就不需要离开本机了，然而这种没有经过源地址转换的回包是不会被认可的，所以，这种部署方式存在较大弊端，尤其是一个服务器上部署多个应用时，应用之间的频繁调用就必然会遇到这个问题。

 

改进方案：

 

如果请求发起总是在APP上，则上述模式工作的会比较好；

但是，还有情况需要考虑，nginx做内部重定向的情况也是非常常见的，当访问a.i.phpor.net 时，很可能需要nginx直接内部转发到b.i.phpor.net ，这是，请求发起者是nginx，为了节省资源，b.i.phpor.net 也是使用的同样的负载均衡和nginx，于是，又出现了前面所讨论的问题。

 

再次改进，确保nginx不会重定向请求到负载均衡，毕竟还是要回来，索性在nginx上稍微麻烦一些，直接转发到自己，或者nginx上将所有自己能提供的服务的域名都解析到127.0.0.1

ssh 之远程端口转发与本地端口转发

如图：

Local B想访问Remote B的80端口，但是由于网络限制，访问不到，但是，Local A可以访问Remote A的22端口，于是：

这样就可以在Local A上listen一个80端口，将接收到的数据包转发给Remote B的80端口

由于listen的端口在本地，所以叫做本地端口转发。

-f 选项： 后台执行

-N 选项： 不执行任何命令，仅仅是用于端口转发

 

同样是Local A可以主动访问Remote A，但是Remote A不能ssh访问Local A，我们想让Remote B能访问Local B的80端口，如何做呢？（注意： 这里并不是上述逻辑的一个翻版）

命令：

这样就可以在Remote A上listen一个80端口，将接收到的数据转发到Local B的80端口；

由于listen的80在远端，所以叫远程端口转发

 

相关原理：

当通过端口转发创建虚线中的连接时，local A和remote A 之间并不会创建一个新的tcp连接，而是在原有tcp连接上创建了新的channel，这个可以在ssh 时 -vvvv看到相关信息

 

如果想要以daemon的形式只做端口转发，不想交互式的登录的远程机器，可以使用-f -N选项，如下：

如果想30分钟后失效，则可以：

H3C 之 nat

首先进入接口上下文：

interface g0/1

对于nat出去的话，使用nat outbound 如：

nat outbound   #所有的地址都可以通过默认的ip地址出去

或

nat outbound [ $acl-number ]  [ address-group $address-group-number ]   #指定的acl 通过指定的地址组中的ip地址出去

 

 

对于nat进来的话，使用nat server 如：

nat server protocol tcp global $ip $port inside $in_ip $in_port

其中 ：

$ip  可以是该接口上的任意某个IP

$port 可以是任意希望暴露的端口

$in_ip  转发到内部的IP

$in_port 转发到的内部的端口

H3C 路由器之Qos

 

http://www.h3c.com/cn/d_201308/794662_30005_0.htm#_Toc364928020

 

 

acl 是符合一定规则的集合

流分类是符合一系列acl的集合

流行为是允许或不允许

Qos 是一组规则，说的是什么样的流分类执行什么样的流行为

最后可以在接口的上下文中应用预先定义好的Qos

Java webserver 内存爆炸Debug

现象：

只要访问指定的某个url，webserver就会很快死掉，直接原因是，内存消耗太多被oom

分析：

其实，这种问题多半是从数据库中一次查询太多数据所致，更直白说就是sql select查询时没有添加limit限制，基本没必要继续查，开发人员闭眼思考3秒就应该知道是哪条sql导致的了，多余的debug都是浪费时间。

但是，有些开发人员就觉得自己遇到了什么高深的bug似的，不见棺材不掉泪，不到黄河不死心，毕竟就算刻意让他写一个消耗内存的程序，都不见得能写出来，所以，下面就简述一下How to debug。

 

办法1：

通过sql-sniffer工具（或者mysqldump）抓包，看看请求都触发了哪些sql语句，一般也能看出来了。

 

办法2：

不断地jstack 该java进程，然后触发url请求，分析最后一次堆栈，通过进程死前的堆栈也能分析出来进程是死在哪里的

eg：

 

办法3：

通过ulimit -c 设置，让进程死时留下一个core文件，然后分析core文件

 

 

nginx if 语句

  • 不能多重判断，错误写法如：
  • 不能嵌套，错误写法如：
  • 条件前件不能为字符串，只能为变量，错误写法如：

相对简单可行的办法：

还有不太严谨的做法：

因为对于多数程序来讲， /abc?var=xyz  与 /abc?var=xyz&_=123456   是一样的，但是后者就不能被不严谨的nginx写法匹配到

实际用例：

PHP redis session 阻塞问题

现象

php 进程： THREAD_PHP_RD_\Service\Process\Deploy 不干活了，进程堆栈如下：

4个cli进程都阻塞在了这里；

大概意思为，PHP要回写session，先要一些其它交互，期望能读一行，但是，怎么也读不够一行，于是就死等

问题1：

如果没有什么意外的话，不应该让死等

问题2：

debug发现，这个stream的数据结构中，设置的超时时间为86400秒:

难怪一直阻塞住不干活。

 

解决办法：

添加超时时间的配置：

 

问题：

你问我gdb的时候是如何知道stream中如何获取超时时间的？如何知道stream->abstract 的真实数据类型的？

翻代码看到的：

 

注： 还以为此事为偶发，进程刚刚工作几个小时就全部进入到了这个场景了,还好我解决了； 其实，这并没有找到问题的根源，不找到原因的话，后续会有更加莫名其妙的的事情发生的

 

Redis 版本号

（然而现在该扩展已经开发到了4.x.y 了