接上一跳评论,理解错题意了, win 下的机制比较诡异.

1. 多线程实际上还是利用单核, 直接用多进程.
2. Python 在共享全局变量这块做的不太好, 多线程场景可以查询下 thread local 相关的资料.
多进程考虑 multiprocessing 的 value 机制, multiprocessing 支持一个 daemon 进程维护这组变量, 多进程通过 IPC

@henryho914 那个库实现的代码写复杂了, 可以看我的一篇文章, 由简单的需求衍生出来的库的历史,
大致上是一个演进的过程, 提供 metaclass 的使用案例, 可能帮助你理解你现在的场景需求.
[ 应用于 Restful 接口的错误码设计 – ErrorCode Class(Python) ]( http://www.kaka-ace.com/restful_api_error_code_design_for_python/)

只说一句话改的太轻松了, 不负责任 或者 业务线访问量就很小, 价值不大的场景......

1. 如果属于底层基础库, 修改类似以下的规则. 如果仅仅是单个业务层的代码, 调用少可以替换再部署上线.
2. 根据你的编程语言, eg: py 类就加新的类名, 然后 B = A 引用赋值.
3. 根据你熟悉的业务场景依次修改并观察线上日志收集平台, 注意是否有涉及接口的 error 信息
4. 如果是快废弃的代码, 真的没必要再操心.
5. 保证业务运行正常是首要的.

贴个地址: https://pypi.python.org/pypi/kkconst

安利下我的作品 kkconst

sendcloud

@siteshen 源码里有一个文件 ketama.py, 类似 mc 的 client 机制. 至于要严格在同一个 node ，可能你的场景要求高. 如果纯粹是当做 mc 原来的使用目的, 这个项目也足够了, 再把 redis 禁止 save, 纯缓存服务.
至于要用到 list 当队列操作 push pop, 这个场景不适合.

我猜想的是题主的运行环境是一个纯缓存的业务, 替换 mc.

pipeline 或者 lua 之类的操作, 使用豌豆荚 codis 比较合理, 这类需求出发的设计的话, redis client 的不应该自己实现调度, 而是得写一套中间服务的 proxy. redis-client 只需要做的是 从配置文件或者发现服务取 proxy 地址即可, 那么用原生的 redis-py 配置上现有的框架能满足大多数通用需求. 而且与后端数据服务是如何实现是隔离屏蔽的，不需要了解后端数据接口的具体实现.

@rogwan
抱歉, nginx 还需要加上:
proxy_pass_header Server;

headers.environ.get("HTTP_X_Forwarded_For", headers.get('HTTP_X_REAL_IP', request.remote_addr))

大多数时候，支持上万并发并没有什么卵用, 你只需要好好写逻辑代码，甚至用个开放的工具都行,
其实当你想着上万并发这个事情，而且朋友还想让人帮忙的想法，实际上是不靠谱的事情, 上万的需求
很可能是 YY 的.

可能是 session 之前的操作抛出了异常, 但没有 rollback.
你的场景可能是批量写，遇到异常时处理下，并输出 log.

web application 里用的 session, 每次 request 其实也可能存在这个问题, 但多数时候没发现是因为
设置 autocommit 之类或者严格处理 rollback, 另外框架可能会帮你 session.close

注意是有 session.close 这部，在 commit/rollback 之后的操作, 因此在之后请求来时，不会出现
这个问题.

@kaneg 最好的依据是以场景来说的, 当你需要大量做消息推送的业务时, 代码易用并没有什么用, 而切换其他语言, 比如 Golang 等高性能语言, 或者使用 pycurl 才是符合利益需求, requests 的效率并不高效

requests 能帮你节省时间, 至于牛不牛逼是按自己场景来的,

* 比如做推送, web业务服务器通过调用 celery task 来避免 友盟/个推的推送接口阻塞.
调用 celery task 也是阻塞的, 但是你的 celery woker 部署在自己同个机群节点里, 甚至
一个交换机上, 假设阻塞延时在 10ms级别, 而如果业务直接调用 http 请求, 可能在100ms级别.

* 如果推送业务频繁, 那么 celery worker 在使用 request 发送 http 请求的性能就比不过 pycurl 了.
业务少使用 requests, 或者自己写测试脚本使用非常方便.
推送量大, 使用 pycurl. pycurl 的易用性没有 requests 高.

* 需求繁忙的时候, 性能和易用需要有个折中, 工作上有充分的时间，自己把 pycurl 或者
使用 human-curl 这个库封装或者修改为自己方便使用的方式, 当然是理想的.