分类：计算机应用

使用树莓派部署nginx服务器提供dns负载

之前买了一个小小的树莓派,一直在吃灰. 本来自己也有一个对外的博客域名,就想怎么样将此机器用起来.(本来就长年24小时开机,当简单的闹钟用)
本文章的目的是让树莓派工作起来,并没有一定技术上的特定优势,仅作技术验证以及耗电技术验证.
先说一下我这边的硬件和网络环境
1 linode云主机,cpu 1核,内存 1g,对外公网ip,地址新加坡(备案你懂的), nginx,mysql,php程序,之前是独立wordpress应用
2 树莓派3代,没部任何程序 上海电信家庭宽带 封80端口(后来发现的) 路由器可作内网转发

做负载均衡有很多种做法,根据当前的网络环境,以及硬件设备.对于像wordpress这种博客应用来说,有以下两种

1 后端应用负载
即使用一个前端nginx,后端通过挂一个upstream,将相应的请求代理到2个后端应用中.
这样的好处在于,应用始终访问一个对外地址,由统一的代理程序决定如何访问后端应用,并且也可以根据后端的实际情况设置权重.nginx上设置代理也简单.
不足之处,也有许多,主要是后端应用需要部署多套,并且相应的底层存储数据需要共享或者是复制.
1.1 在树莓派上就需要安装mysql,php这种应用,同时要开始公网数据同步,开销可能有点大.树莓派本身能不能支持mysql这种不算小型的数据库,内存和cpu占用都是未知问题.
1.2 前端代理访问,nginx之前安装在linode主机,当前也不准备更换,如果代理到树莓派,就意味着访问先从国内访问到linode,然后linode再内部访问到树莓派,中间的延时肯定会有问题
1.3 当然也可以将nginx放在树莓派国内电信上,不过鉴于电信宽带本身的稳定性(ip变化,断电,或者临时被封等),肯定比不上固定的云主机,而且树莓派一挂,整个博客即挂掉

2 访问前端负载
更往前一点就可以作dns负载, 通过dns解析域名时产生多个ip,让访问者随机选择1个进行访问.
好像在于,原linode应用不作任何调整,接下来就工作就是让访问树莓派时能够输出相应的内容即可
不足之处,在于当前的dns解析(使用的dnspod)当前还不能作权重,不能设置权重信息. 树莓派不用后端处理,那么就需要加速访问才能达到效果.

最后的方案就是dns负载,树莓派加速网络访问,整个步骤如下

  1. 搭建支持https以及lua脚本支持的nginx
  2. 加速GET请求处理
  3. 反向代理POST请求
  4. 反向代理wp-admin后台管理
  5. dns负载配置,ip动态更新
  6. 树莓派小尾巴

继续阅读“使用树莓派部署nginx服务器提供dns负载”

mysql中错误码1406 data too long在jdbc和命令行的不同表现及处理

今天在同事开发过程中碰到一个mysql的错误码:1406,显示的错误信息为 data too long for column,而导致相应的事务被回滚.将此错误码(google 关键字 mysql 1406),即搜索到相应的错误信息,即相应的插入数据比实际的列的大小更大.然后,报相应的错误信息,最终处理失败.

但是,对于这条sql语句,如果将语句贴到命令行去执行,即得到另外一个结果.sql不会报错,但再次查询相应的数据信息,会发现插入的数据被自动截断了.在这种情况下,实际上插入的数据是错误的,即因为不同的行为得到不同的结果.

然后,再次google(关键字 mysql自动截断)会发现这两种情况是因为使用了不同的sql_mode导致.获取相应的sql_mode命令可以如下所示(笔者mysql为mariadb 10.1)

select @@sql_mode;

获取的数据信息为:NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION.

这种情况下,即会产生自动截断的设置.可以通过set @@sql_mode="xxx"来修改.影响截断地设置为 strict_trans_tables 或者 strict_all_tables.将其设置为其中之一即可.

反之,使用默认的jdbc连接mysql时,同样通过命令获取相应的数据,结果为
NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
会发现相应的设置并不与命令行相同.

这里的原因在于,在mysql的jdbc驱动中,之前也是与命令行相同,但为了保证与jdbc规范相符(具体的规范没找到),引入了配置变量 jdbcCompliantTruncation.此变量可以在连接字符串中,追加并设置为false.其默认值为true.
在具体的mysql jdbc实现中(当前版本为5.1.39),此变量会在类ConnectionImpl中判定.如果为true,并且版本大于5.0.2,则会发语句set sql_mode=xxx 来进行重新设置.其重新设置的值,即在之前提到值的基础之上,追加值 STRICT_TRANS_TABLES. 然后,在此设置的影响下,插入数据超长即会直接报错,而不是自动截断.

继续阅读“mysql中错误码1406 data too long在jdbc和命令行的不同表现及处理”

使用nod32导致客户端响应中没有gzip压缩标识的问题

之前在本机研究dropwizard时,本着默认的情况下应该开启gzip压缩,因此在相应的yml配置中开启gzip标记(它本身也是开启的).但是在相应的请求返回中并没有出现相应的gzip标识,在chrome浏览器下的标识信息为如下的响应所示:

从上面的标识来看,在响应头上并没有gzip标识.
然后开始痛苦的处理过程,从浏览器,客户端,服务端,然后最后从网络层逐步处理,最终找到问题的原因及出处.

继续阅读“使用nod32导致客户端响应中没有gzip压缩标识的问题”

haproxy和keepalived的个人理解

附参考文:http://weizhifeng.net/HA-with-HAProxy-and-KeepAlived.html

关于此两者，随便google一下都会有大量的文章，因此这里也不用介绍如何来进行安装和配置了。主要从一个整体方案的角度来描述什么要这样做，以及这样做所解决的问题。

所有的系统，都是先经历一个单台机器搞所有业务的时代，一个程序+一个mysql数据库，就可以满足开发及第一个版本上线的要求。随着，数据的增加以及业务的增长，这些应用就面临一个访问量的扩大以及扩展的问题。最简单的扩展就是水平扩展，原来由一个mysql增加为2个或多个，形成一个集群，这样最简单的能力就是提供更强的服务能力。如原来的访问量支持每秒1000，现在可以支持2000(理想值)，相当于将服务能力分散到多个节点。
这里面涉及到多个问题，首先就是数据的相互备份，然后就是如何分配计算能力，外部如何来访问等。本文引入HaProxy和KeepAlived主要处理的就是一个外部访问问题。

在后面的介绍当中，假定有2个mysql，分别为mysqlA和mysqlB.

继续阅读“haproxy和keepalived的个人理解”

thinkpad w540在win8下休眠或合上盖子屏幕不亮的解决方法

本文来自讨论:https://forums.lenovo.com/t5/W-Series-ThinkPad-Laptops/W540-Blank-screen-after-undocking-sleep/td-p/1768605

笔者笔记本w540装上win8(或windows 2012)之后，出现一个现象，只要盒上盖子，或者是自动休眠之后，重新打开笔记本，屏幕始终就不亮了。只有直接按电源重新启动，但只要再次休眠，同样的情况就会出现。不仅是这样，只要合上盖子，这个问题也会出现，还能不能愉快地工作了…

经google，搜到前端提到的帖子，此问题还是软件驱动的问题。驱动在休眠之后，不能自动唤醒屏幕，或者说不知道LCD屏幕的存在。解决此问题办法也很简单。按下面步骤即可：

  • 卸载原来笔记本自带的intel驱动，在我的电脑，右键属性，设备管理器，选择显卡，选择intel HD 4600,右键卸载，并且选择删除驱动程序。
  • 下载旧版本的intel驱动，地址：https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=24329 。即版本：3958的版本，下载完安装。
  • 重启，问题解决:)

http中chunked编码的特殊编码头

在进行Http传输中，可以通过设置Transfer-Encoding以进行传输编码。其中chunked编码表示分块进行数据传输，其通过一个0长度的chunk块表示数据传输完毕。对于在传输过程中的chunked块，则通过以下的一个数据格式进行描述：

chunk-size 
[ chunk-extension ] 
CRLF 
chunk-data 
CRLF

不考虑chunked-extension属性，则可以理解为先描述块长度，然后接回车换行，接下来再描述相应长度的数据信息，最后接回车换行符，即完成一个chunk编码信息。

这里的chunk-size，与其它的传输不同，这里需要设置为 16 进制数字字符串。即不是传输认为的设置一个长度值即可。对于一个长度值为255的chunk块，其16进制为ff(小写表示)，直接编码即为 ff。但这里要求为数字字符串，即以字符串的方式来描述编码值，编码为'f''f'，针对f字符的编码值为 66(16进制)，那么255长度的实际编码值即为 66 66。

一个255长度的编码片断，类似如下所示：

如上所示的标记处，前面为头结束的2个CRLF值。

在Http编码中，只有这里的chunked编码有点特别。其它的长度信息如content-length值等，都是使用正常的长度值(16进制)，确实有点奇怪。在编码时，如果对这里的编码头没写正确，那么输出到客户端的数据永远都是错的…