python共享内存mmap

---

一、python标准库有哪些Python标准库的内容涵盖了广泛的功能，包括文件、字符串和数字处理、数据结构、网络编程、操作系统用户界面、网页测试、线程和其他工具。
具体来说，1、文件操作、OS、OS相关的模块。
Path、shutil、errno、stat、glob、fnmatch、tempfile等。
2.字符串和文本处理模块，string、re、difflib、textwrap等。
3.数据结构形式、集合、二等分、数组、堆、队列、结构、弱引用等。
4.网络编程和操作系统、SocketServer、套接字、选择器、线程、多处理、子进程、mmap、sched、asyncore等。
5.网页测试，urllib、urllib2、httplib、ftplib、gopherlib、spider等。
6.解析和处理XML、HTMLParser、ElementTree、XMLParser、XMLWriter、SAX、minidom、expat等。此外，还包括其他有用实用的部分，如BaseHTTPServer、CGIHTTPServer、Cookies、Templates、xmlrpclib、Formatter、Email等。
此外，Python还支持第三方库和架。有很多实用的框架和工具可以让开发者高效、便捷地完成家庭任务。

---

二、如何用Python一门语言通吃高性能并发，GPU计算和深度学习第一个是并发本身带来的开销，即打开新的处理线程、关闭处理线程以及多个处理线程的时间片轮换带来的开销。
事实上，对于一些逻辑不太复杂的场景，这些开销甚至比实际处理代码逻辑部分的开销还要大。所以我们决定采用一种基于协程的并发方式，即只有一个服务进程（单CPU），所有请求数据都由这个服务进程内部维护。同时，服务进程自行调度不同请求的处理顺序，从而避免了传统的多线程流程。以并发方式创建、销毁和系统调度处理线程的开销。基于这样的考虑，我们选择基于Tornado框架来开发api服务。Tornado的实现非常简单明了。它使用python的生成器作为协程，并使用IOLoop来实现调度队列。
第二个问题是数据库的性能。这里提到的数据库包括MongoDB和Redis。我在这里分别说一下。
我们先来说说MongoDB。MongoDB主要存储不同用户的不同设置以供验证，比如应该显示什么样的图片。
一开始，每个验证请求都会查询MongoDB。当时我们的MongoDB是纯内存的，三台机器组成一个复制集。这个组合可以稳定承载八九千qps。后来，随着我们验证体积的增大，这个承载能力逐渐成为我们的瓶颈。
为了彻底解决这个问题，我们提出了最极端的解决方案，就是直接将数据库中的数据缓存到服务进程中，定期量更新。这样，查询开销就会大大减少。但由于我们使用的是Python，由于GIL的存在，在8核服务器上会fork出8个服务进程。进程没有线程方便，所以我们基于mmap写了一套伙伴算法来构建跨进程的Process共享缓存。自从这个缓存上线后，Mongodb的负载几乎变成了零。
说完MongoDB，我们来说说Redis的问题。Redis代码简单，数据结构丰富，性能强大。唯一的问题是，作为单进程程序，毕竟性能是有上限的。
虽然Redis今年发布了正式的集群版本，但经过我们的测试，我们认为这种分布式解决方案的故障恢复时间不够好，运维成本较高。在官方Redis集群方案发布之前，开源界有很多代理方案，比如Twitter的TwemProxy、豌豆荚的Codis等。经过测试这两种方案，我们感觉TwemProxy的运维还是比较麻烦。Codis用起来非常清爽。无论是修改配置还是扩容，都可以在配置页面完成，而且性能还不错，但我们当时很无奈。Codis仍然存在严重的Bug，只能放弃。
几乎尝试了各种解决方案后，我们仍然决心自己实现一个分布式解决方案。目的是高度满足我们的需求，并且运维成本低、扩展方便、故障切换快。最重要的是，数据冗余一定要做好。
基于以上考虑，我们确定了基于客户端的分布式方案，并使用zookeeper来同步状态，保证高可用。具体来说，我们修改Redis源代码，使其注册到zookeeper。客户端从zookeeper获取Redis服务器集群信息，并根据统一一致性哈希算法计算出数据应该存储在哪个Redis上，并在哈希环中进行计算。在下一个Redis上写入冗余数据。当读取原始数据失败时，您可以立即尝试读取冗余数据，而不会造成服务中断。