Python适合编写对运算速度有较高要求的实时程序

Python适合编写对运算速度有较高要求的实时程序,第1张

Python适合用于编写对运算速度有较高要求的实时程序。

Python提供了巧旅岩高效的高级数据结构,还能简单有效地面向对象编程。

由于Python编程语言简单、灵活、易上手,运算速度快,很受现在开发者的喜爱,现在多个国家的程序镇蠢员使用Python编程语言也越来越多,呈直线上升趋孝御势。

一、Python代码编辑器

1、sublime Text

sublime

Text是一款非常流行的代码编辑器,支持Python代码编辑,同时兼容所有平台,并且丰富的插件扩展了语法和编辑功能,迅捷小巧,具有良好的兼容性,很受编程人士的喜爱。

2、Vim

Vim和VI是一种模型编辑器,它将文本查看从文本编辑中分离,VIM在原始VI之上做了诸多改进,包括可扩展模型和就地代码构建,VIMScripts可用于各种Python开发任务。

3、Visual Studio Code

Visual Studio Code是一款兼容Linux、Mac OS

X和Windows平台的全功能代码编辑器,可扩展并且可以对几乎所有任务进行配置,对于Python的支持可以在Visual Studio

Code中安装插件,只需快速点击按钮即可成功安装,且可自动识别Python安装和库。

二、Python集成开发环境

1、PyCharm

PyCharm是唯一一款专门面向Python的全功能集成开发环境,同样拥有付费版和免费开源版,PyCharm不论是在Windows、Mac OS

X系统中,还是在Linux系统中谈世都支持快速安装和使用。

PyCharm直接支持Python开发环境,打开一个新的文件然后就可以开始编写代码,也可以在PyCharm中直接运行和调试Python程序,它还支持源码管理和项目,并且其拥有众多便利和支持社区,能够快速掌握学习使用。雀汪

2、顷侍仔Spyder

Spyder是一款为了数据科学工作流做了优化的开源Python集成开发环境,它是附在Anaconda软件包管理器发行版中的,Spyder拥有大部分集成开发环境该具备的功能,如强大语法高亮功能的代码编辑器、Python代码补全以及集成文件浏览器,其还具有其他Python编辑环境中所不具备的变量浏览器功能,十分适合使用Python的数据科学家们。

3、Thonny

Thonny是针对新手的一款集成开发环境,适用于全部主流平台,默认情况下,Thonny会和自带捆绑的Python版本一起安装,十分方便新手使用。

第一个就是并发本身所带来的开销即新开处理线程、关闭处理线程、多个处理线程时间片轮转所带来的开销。

实际上对于一些逻辑不那么复杂的场景来说这些开销甚至比真正的处理逻辑部分代码的开销更大。所以我们决定采用基于协程的并发方式,即服务进程只有一个(单cpu)所有的请求数据都由这个服务进程内部来维护,同时服务进程自行调度不同请求的处理顺序,这样避免了传统多线程并发方式新建、销毁以及系统调度处理线程的开销。基于这样的考虑我们选择了基于Tornado框架实现api服务的开发。Tornado的实现非常简洁明了,使用python的生成器作为协程,利用IOLoop实现了调度队列。

第二个问题是数据库的性能,这里说的数据库包括MongoDB和Redis,我这里分开讲。

先讲MongoDB的问题,MongoDB主要存储不同的用户对于验证的不同设置,比如该显示什么样的图片。

一开始每次验证请求都会查询MongoDB,当时我们的MongoDB是纯内存的,同时三台机器组成一个复制集,这样的组合大概能稳定承载八九千的qps,后来随着我们验证量越来越大,这个承载能力逐渐就成为了我们的瓶颈。

为了彻底搞定这个问题,我们提出了最极端的解决方案,干脆直接把数据库中的数据完全缓存到服务进程里定期批量更新,这样查询的开销将大大降低。但是因为我们用的是Python,由于GIL的存枯橡在,在8核服务器上会fork出来8个服务进程,进程之间不像线程那么方便,所以我们基于mmap自己写了一套伙伴算法构建了一个跨进程共享缓存。自从这套缓存上线之后,Mongodb的负载几乎变成了零。

说完了MongoDB再说Redis的问题,Redis代码简洁、数据结构丰富、性能强大,唯一的问题是作为一个单进程程序,终究性能是有上限的。

虽然今年Redis发布了官方的集群版本,但是经过我们的测试,认为这套分布式方案的故障恢复时间不够优秀并且运维成本较高。在Redis官方集群方案面世之前,开源世界有不少proxy方案,比如Twtter的TwemProxy和豌豆荚的Codis。这两种方案测试完之后给我们的感觉TwemProxy运维还是比较麻烦,Codis使用起来让人非常心旷神怡,无论是修改配置还是扩容都可以在配置页面上完成,并且性能尘樱也还算不错,但无奈当时Codis还有比较严重的BUG只能放弃之。

几乎尝试过各种方案之后,我们还是下决心自己实现一套分布式方案,目的是高度贴合我们的需求并且运维成本要低、扩容要方便、故障切换要快最重要的是数据冗余一定要做好。

基于上面的考虑,我们确定基于客户端的分布式方案,通过zookeeper来同步状态保证高可用。具体来说,我们修改Redis源码,使其向zookeeper注册,客户端由zookeeper上获取Redis服务器集群信息并根据派败丛统一的一致性哈希算法来计算数据应该存储在哪台Redis上,并在哈希环的下一台Redis上写入一份冗余数据,当读取原始数据失败时可以立即尝试读取冗余数据而不会造成服务中断。


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/yw/8260075.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-04-14
下一篇 2023-04-14

发表评论

登录后才能评论

评论列表(0条)

保存