Django: Python Web应用开发框架
Django 应该是最出名的Python框架，GAE甚至Erlang都有框架受它影响。Django是走大而全的方向，它最出名的是其全自动化的管理后台：只需要使用起ORM，做简单的对象定义，它就能自动生成数据库结构、以及全功能的管理后台。
Diesel：基于Greenlet的事件I/O框架
Diesel提供一个整洁的API来编写网络客户端和服务器。支持TCP和UDP。
Flask：一个用Python编写的轻量级Web应用框架
Flask是一个使用Python编写的轻量级Web应用框架。基于Werkzeug WSGI工具箱和Jinja2
模板引擎。Flask也被称为“microframework”，因为它使用简单的核心，用extension增加其他功能。Flask没有默认使用的数
据库、窗体验证工具。
Cubes：轻量级Python OLAP框架
Cubes是一个轻量级Python框架，包含OLAP、多维数据分析和浏览聚合数据（aggregated data）等工具。
Kartograph.py：创造矢量地图的轻量级Python框架
Kartograph是一个Python库，用来为ESRI生成SVG地图。Kartograph.py目前仍处于beta阶段，你可以在virtualenv环境下来测试。
Pulsar：Python的事件驱动并发框架
Pulsar是一个事件驱动的并发框架，有了pulsar，你可以写出在不同进程或线程中运行一个或多个活动的异步服务器。
Web2py：全栈式Web框架
Web2py是一个为Python语言提供的全功能Web应用框架，旨在敏捷快速的开发Web应用，具有快速、安全以及可移植的数据库驱动的应用，兼容Google App Engine。
Falcon：构建云API和网络应用后端的高性能Python框架
Falcon是一个构建云API的高性能Python框架，它鼓励使用REST架构风格，尽可能以最少的力气做最多的事情。
Dpark：Python版的Spark
DPark是Spark的Python克隆，是一个Python实现的分布式计算框架，可以非常方便地实现大规模数据处理和迭代计算。DPark由豆瓣实现，目前豆瓣内部的绝大多数数据分析都使用DPark完成，正日趋完善。
Buildbot：基于Python的持续集成测试框架
Buildbot是一个开源框架，可以自动化软件构建、测试和发布等过程。每当代码有改变，服务器要求不同平台上的客户端立即进行代码构建和测试，收集并报告不同平台的构建和测试结果。
Zerorpc：基于ZeroMQ的高性能分布式RPC框架
Zerorpc是一个基于ZeroMQ和MessagePack开发的远程过程调用协议（RPC）实现。和 Zerorpc 一起使用的 Service API 被称为 zeroservice。Zerorpc 可以通过编程或命令行方式调用。
Bottle: 微型Python Web框架
Bottle是一个简单高效的遵循WSGI的微型python Web框架。说微型，是因为它只有一个文件，除Python标准库外，它不依赖于任何第三方模块。
Tornado：异步非阻塞IO的Python Web框架
Tornado的全称是Torado Web Server，从名字上看就可知道它可以用作Web服务器，但同时它也是一个Python Web的开发框架。最初是在FriendFeed公司的网站上使用，FaceBook收购了之后便开源了出来。
webpy: 轻量级的Python Web框架
webpy的设计理念力求精简（Keep it simple and powerful），源码很简短，只提供一个框架所必须的东西，不依赖大量的第三方模块，它没有URL路由、没有模板也没有数据库的访问。
Scrapy：Python的爬虫框架
Scrapy是一个使用Python编写的，轻量级的，简单轻巧，并且使用起来非常的方便。
主要用于分散压力，所以分布式的服务都是部署在不同的服务器上的，再将服务做集群
根据“分层”的思想进行拆分。
例如，可以将一个项目根据“三层架构” 拆分
然后再分开部署 ：
根据业务进行拆分。
例如，可以根据业务逻辑，将“电商项目”拆分成 “订单项目”、“用户项目”和“秒杀项目” 。显然这三个拆分后的项目，仍然可以作为独立的项目使用。像这种拆分的方法，就成为垂直拆分
主要用于分散能力，主要是将服务的颗粒度尽量细化，且自成一脉，压力这块并不是其关注的点，所以多个微服务是可以部署在同一台服务器上的
微服务可以理解为一种 非常细粒度的垂直拆分 。例如，以上“订单项目”本来就是垂直拆分后的子项目，但实际上“订单项目”还能进一步拆分为“购物项目”、“结算项目”和“售后项目”，如图
现在看图中的“订单项目”，它完全可以作为一个分布式项目的组成元素，但就不适合作为微服务的组成元素了（因为它还能再拆，而微服务应该是不能再拆的“微小”服务，类似于“原子性”）
分布式服务需要提供给别的分布式服务去调用，单独拆出来 未必外部可用
微服务自成一脉，可以系统内部调用，也可以单独提供服务
为什么需要用分布式锁，见下图
变量A存在三个服务器内存中（这个变量A主要体现是在一个类中的一个成员变量，是一个有状态的对象），如果不加任何控制的话，变量A同时都会在分配一块内存，三个请求发过来同时对这个变量操作，显然结果是不对的！即使不是同时发过来，三个请求分别操作三个不同内存区域的数据，变量A之间不存在共享，也不具有可见性，处理的结果也是不对的。
分布式锁应该具备哪些条件：
1、在分布式系统环境下，一个方法在同一时间只能被一个机器的一个线程执行；
2、高可用的获取锁与释放锁；
3、高性能的获取锁与释放锁；
4、具备可重入特性；
5、具备锁失效机制，防止死锁；
6、具备非阻塞锁特性，即没有获取到锁将直接返回获取锁失败
Redis性能高
命令简单，实现方便
使用setnx加锁，key为锁名，value随意不重复就行（一般用uuid）
给锁添加expire时间，超过该时间redis过期（即自动释放锁）
设置获取锁的超时时间，若超过时间，则放弃获取锁
通过锁名获取锁值
比较锁值和当前uuid是否一致，一致则释放锁（通过delete命令删除redis键值对）
2PC：two phase commit protocol，二阶段提交协议，是一种强一致性设计。
同步阻塞（导致长久的资源锁定） ，只有第一阶段全部正常完成（返回失败，回字返回超时都会返回 “准备失败” ），才会进入第二阶段
因为协调者可能会在任意一个时间点（发送准备命令之前，发送准备命令之后，发送回滚事务命令之前，发送回滚事务命令之后，发送提交事务命令之前，发送提交事务命令之后）故障，导致资源阻塞。
T：try，指的是预留，即资源的预留和锁定，注意是预留
C：confirm，指的是确认操作，这一步其实就是真正的执行了
C：cancel，指的是撤销操作，可以理解为把预留阶段的动作撤销了
从思想上看和 2PC 差不多，都是先试探性的执行，如果都可以那就真正的执行，如果不行就回滚。
适用于对实时性要求没那么高的业务场景，如：短信通知
![r语言中x=coords[,1]是什么意思](/aiimages/r%E8%AF%AD%E8%A8%80%E4%B8%ADx%3Dcoords%5B%2C1%5D%E6%98%AF%E4%BB%80%E4%B9%88%E6%84%8F%E6%80%9D.png)
