在很早的时候，就听网上的文章说:

python有GIL，所以在单进程内，即使使用多线程也无法利用到多核的优势，同一时刻，python的字节码只会运行在一个cpu上。

以前也是奉为真理，直到今天在对自己的python server做性能测试的时候，发现一个python进程的cpu居然达到了120%。

当用c++编程的时候，如果使用多线程，那么确实进程cpu超过100%非常正常，但是对python来说，似乎这样就和网上的文章冲突了。

所以还是决定自己亲身试验一下，编写代码如下：

from thread import start_new_thread

def worker():
    while 1:
        #print 1
        pass

for it in range(0, 15):
    start_new_thread(worker, ())


raw_input()

运行环境为： centos6.4 64位， python 2.7.

得到的结果如下:

可以清楚的看到，pid为31199的python进程cpu达到了787.9%，接近理论能达到的最大值 800%。

而上方的8个cpu也分别达到了近100 ...

最近在做游戏服务分层的时候，一直想把mysql的访问独立成一个单独的服务DBGate，原因如下:

1. 请求收拢到DBGate，可以使DBGate变为无状态的，方便横向扩展
2. 当请求量或者存储量变大时，mysql需要做分库分表，DBGate可以内部直接处理，外界无感知
3. 通过restful限制对数据请求的形式，仅支持简单的get/post/patch/put 进行增删改查，并不支持复杂查询。这个也是和游戏业务的特性有关，如果网站等需要复杂查询的业务，对此并不适合
4. DBGate使用多进程模式，方便控制与mysql之间的链接数，进行mysql访问量阀值保护
5. 方便在DBGate上进行访问量统计，慢查询统计、权限控制等等一系列逻辑
6. 目前是使用python，以后要使用其他语言进行mysql操作时，只要进行标准的http请求即可，不会出现不兼容的情况

当然坏处也是有的：

1. 首当其冲就是单次请求的响应时间变长，毕竟中间加了一层服务，并且还是http格式
2. 部署上比原来复杂了一些，很多对mysql直接操作的思维需要进行转变，一开始可能会有些不适

不过总的来说，还是利大于弊，所以最终还是决定搭建DBGate

当然，我们不可能去手工挨个写每个库表对应的restful服务，值得庆幸的是django和flask都提供了对应的解决方案，我们一个个介绍.

Flask

参考链接: flask-restless

flask-restless使用方法比较简单，我直接贴一下代码即可:

# -*- coding: utf-8 -*-

import datetime
from flask ...

最近在调整游戏的后台架构，之前因为需要快速出产品，所以整个代码都揉成一团，也基本没有做任何分层处理。现在服务器端的开发也开始逐渐招进来，所以打算打算换一套统一的架构，以后做新游戏只要做其中的业务逻辑即可。

其实之前在腾讯的时候，基本不会用到message queue这种，所有的分布式处理都是由自己写c++ server来互相通信的。这样的处理虽然开发量稍微大一点，但是性能和灵活性确实很高。

现在自己在外面做，虽然自己已经封装了一套server的框架出来，但是毕竟还有太多的轮子需要自己制造，所以就想到了之前一直有了解过celery，来看一下这种基于message queue的任务系统能达到什么性能。

RabbitMQ

celery首推的mq是rabbitmq，所以需要先安装一下:

在mac下用brew 安装：

brew install rabbitmq

安装成功之后，即可启动server了。

不过在这之前，我们先把后台管理的插件打开：

rabbitmq-plugins enable rabbitmq_management

之后执行如下命令，启动server:

rabbitmq-server

这个时候就可以通过 http://127.0.0.1:15672/ 来访问后台管理端了，默认的用户名和密码是guest guest，可以自己在页面上修改。截图如下：

Redis

celery也支持redis作为broker和backend，所以redis也需要安装一下 ...

测了一下django、flask、bottle、tornado 框架本身最简单的性能。对django的性能完全无语了。

django、flask、bottle 均使用gunicorn+gevent启动，单进程，并且关闭DEBUG，请求均只返回一个字符串ok。

tornado直接自己启动，其他内容一致。

测试软件为 siege，测试os为cenos6 64位，测试命令为:

siege -c 100 -r 100 -b http://127.0.0.1:5000/

django测试结果为:

Transactions:		       10000 hits
Availability:		      100.00 %
Elapsed time:		       18.51 secs
Data transferred:	        0.02 MB
Response time:		        0.18 secs ...

上一篇文章聊了下数据存储和常用的传输协议，不过对于自定义传输协议这里留了个坑，正好有点时间，就抓紧填上：）

既然选择原生socket，那么有个基本的选择就是tcp/udp的问题.

这个其实还是看业务自己的选择，只是如果选择了udp的话，那么很多问题都可以不用考虑，比如粘包问题。但是udp有个限制是每次传输的数据大小不能超过64K，这个要注意。

为了考虑复杂的情况，我们还是主要说tcp的实现，这篇文章先说下socket使用相关的一些库和代码吧

Android端开发

对于android端，我们有两个主要选择：阻塞socket和非阻塞socket。

阻塞socket就是正常的socket，当调用recv的时候，会阻塞住直到返回数据。

非阻塞socket在android上可以直接使用nio，因为自己之前一直是做c++和python，所以其实一开始nio的时候真心有些不太使用，把几个要注意的点列一下:

1. 当网络断线的时候，有些手机如S4，会出现这个问题，channel.finishConnect()会一直等超时 60秒。之后会抛出一个 TimeoutException.

解决方法是：

channel.socket().setSoTimeout(5)

来设置成只等5秒。

比较诡异的是，明明是异步io了，为什么还是会有等待超时的情况。还要在研究下。

2. 当网络不在线的时候，启动connect，依然可以进入isConnectable的判断中，并且可以调用finishconnect。

解决方案：finishConnect之后 ...

yunbk 是我前段时间用python写的一个备份插件，取中文谐音云备份的意思，你可以很方便的用这个插件来备份mysql、redis、mongodb、乃至各种media目录，等等。 安装可以直接用pip执行:

pip install yunbk

github地址如下:

https://github.com/dantezhu/yunbk

而用法也非常简单，比如要备份mysql，则代码如下:

from yunbk import YunBK
from yunbk.backend.local import LocalBackend

import sh

backend = LocalBackend('/data/backup')

with YunBK('mysql', [backend]) as ybk:
    sh.mysqldump(u='root',
                 all_databases=True,
                 _out="dump.sql")
    ybk.backup ...

做服务器端开发的同学应该都对进程监控不会陌生，最近恰好要更换 uwsgi 为 gunicorn，而gunicorn又恰好有这么一章讲进程监控，所以多研究了下。

结合之前在腾讯工作的经验，也会讲讲腾讯的服务器监控是怎么做的。同时也会讲下小团队又该怎么敏捷的解决。

下面按照监控的方法依次介绍。

一。按照进程名监控

在腾讯内部所有server都是要打包发布的，而在打包过程中是需要填写要监控的进程名，然后在crontab中定时通过ps查询进程是否存在。

这种方法是比较简单的方法，但是考虑到很多进程会在启动之后改名，以及进程名存在各种特殊字符，多个进程同时存在的问题，实际操作起来并不是很舒服。

举个简单的例子，gunicorn启动之后的进程名类似这样 master: [wsgi:app]，其中的方括号在grep时要记得转义，否则就会出问题。

不过不管怎么说，这种方法在很多其他方式用不了的时候反而是最简单的方法。

下面是用python的实现：

def monitor_process(key_word, cmd):
    p1 = subprocess.Popen(['ps', '-ef'], stdout=subprocess.PIPE)
    p2 = subprocess.Popen(['grep', key_word], stdin=p1.stdout, stdout=subprocess.PIPE)
    p3 ...

写在前面: 博客很久没有更新了，主要是事情实在太多，不过最近也确实做了些比较有价值的事情，后面和大家慢慢分享

笔者在腾讯主要负责开放平台openapi的工作，由于工作关系，这几天遍历了 百度、人人、新浪、淘宝 4个平台，研究了一下他们对于站内应用、网站登录、移动应用的整合方式，并开发了一个百度站内应用的demo。

百度站内应用demo: 体验地址(要体验的话，请先联系我开通白名单): http://app.baidu.com/app/enter?appid=385894&debug=1&is_from_dev=1&canvas_pos=platform

代码已经开源在github上: https://github.com/dantezhu/baidu_app_demo，里面封装了一个baidu的sdk，有需要的朋友可以直接拿去用。

开发语言用的是 python+flask 移动应用 和 网站接入，这两种接入都是走的oauth的方式，这个基本所有平台都是一样的。

而对于站内应用则和腾讯目前不太一样，所以着重说明一下在这里的处理,仅以百度举例:

百度的教程在这里： 百度站内应用开发文档

1. 当用户点击应用列表进入时 ...

离上一次写博有点久了，留言也回复的比较慢，主要事情确实有点多，今天想想还是把这篇给写了吧，可能有点乱。

先说说最近折腾了些啥 部分开源项目的代码从googlecode迁移到github，其实还是主要是svn和git的原因，因为公司一直是用svn，所以对svn会熟一些。

不过最近发现越来越多的项目都在使用github，所以免不了好奇起来，本着越是抵触越是要搞的心理，硬着头皮总算懂了些皮毛。

之前还对git的分布式代码管理没什么感觉，这几天恰巧去上海参加chinajoy，网络时好时坏，svn一直不能ci，这才怀念起git的好来。

所以目前的结论就是，两者都用着，新项目就统一往github上迁移了。

研究了一下bootstrap from twitter，这个号称能让开发人员写出漂亮页面的前端库真心不错，把页面用12个栅格来表示，之前从没想过页面可以这样规划（好吧，也可能是我孤陋寡闻。。），而且支持交互式布局，做出来的界面都iphone、ipad等移动设备都会自动适应，的确是后台开发写前端的一大利器，超赞！

OK，碎碎念结束，接下来还是分享一段代码吧。

关注本博的朋友应该会了解之前我在python的微框架使用flask还是bottle之间选择了很久，现在无论如何，事实就是我多的在用flask，原因就不扯了，反正也扯不清楚。

这里主要是分享一点，无论是django，flask，bottle 都有一个通过 endpoint 生成 url的函数，在django中是reverse(模板中是url)，flask是url_for，bottle中是url ...

这篇文章写的比较晚，主要也是要真正用起来才会发现，django1.4的这次升级在项目目录结构，配置文件上都有比较多的调整，恰好这次也受这样的困扰，所以就拿出来和大家分享一下。 django1.4增加了一个很重要的目录: static，在之前，django的所有静态文件都是放在media目录下的，但是同时用户在后台主动上传的文件也会放到这里，所以会引起一些不必要的混乱. 而且在之前的版本种，django的admin会霸占/media的路径，导致我之前不得不在配置里面强制修改一下:

ADMIN_MEDIA_PREFIX = '/admin_media/'

或者让网站自己的静态文件路径使用的别的前缀:

MEDIA_URL = '/site_media/'

对应的nginx.conf也要做一些相应的配置，对于之前版本相关的内容，这篇文章就不做赘述了，有兴趣的朋友可以去我之前写的博文看一下: linux下nginx+python+fastcgi部署总结(django版)，PS：当时还没用uwsgi，大家将就一下。。 回到我们说的django1.4的变更，增加的static目录用来存放网站需要的静态文件，如css，img等，而/media目录用来存放用户上传的文件，admin使用的静态文件是放到/static/admin下。 这样的调整是要比原来合理很多，但同时nginx.conf的配置也需要做响应的变更，如:

server {
    listen ...