‘壹’ 有哪些Java web里的并发框架，都有哪些
一、并发是一种需求，以下先介绍一下javaweb对于高并发的处理思路：
1、synchronized 关键字
可用来给对象和方法或者代码块加锁，当它锁定一个方法或者一个代码块的时候，同一时刻最多只有一个线程执行这段代码。可能锁对象包括： this， 临界资源对象，Class 类对象
2、同步方法
同步方法锁定的是当前对象。当多线程通过同一个对象引用多次调用当前同步方法时， 需同步执行。
3、同步代码块
同步代码块的同步粒度更加细致，是商业开发中推荐的编程方式。可以定位到具体的同步位置，而不是简单的将方法整体实现同步逻辑。在效率上，相对更高。
A）锁定临界对象
同步代码块在执行时，是锁定 object 对象。当多个线程调用同一个方法时，锁定对象不变的情况下，需同步执行。
B）锁定当前对象
4、锁的底层实现
Java 虚拟机中的同步(Synchronization)基于进入和退出管程(Monitor)对象实现。同步方法 并不是由 monitor enter 和 monitor exit 指令来实现同步的，而是由方法调用指令读取运行时常量池中方法的 ACC_SYNCHRONIZED 标志来隐式实现的。
5、锁的种类
Java 中锁的种类大致分为偏向锁，自旋锁，轻量级锁，重量级锁。
锁的使用方式为：先提供偏向锁，如果不满足的时候，升级为轻量级锁，再不满足，升级为重量级锁。自旋锁是一个过渡的锁状态，不是一种实际的锁类型。
锁只能升级，不能降级。
6、volatile 关键字
变量的线程可见性。在 CPU 计算过程中，会将计算过程需要的数据加载到 CPU 计算缓存中，当 CPU 计算中断时，有可能刷新缓存，重新读取内存中的数据。在线程运行的过程中，如果某变量被其他线程修改，可能造成数据不一致的情况，从而导致结果错误。而 volatile 修饰的变量是线程可见的，当 JVM 解释 volatile 修饰的变量时，会通知 CPU，在计算过程中， 每次使用变量参与计算时，都会检查内存中的数据是否发生变化，而不是一直使用 CPU 缓存中的数据，可以保证计算结果的正确。
更多、此外还有很多细节需要通过学习去了解和完善，此处就不一一列举了。
二、并发框架
并发框架很多，如ExecutorService、RxJava、Disruptor、Akka等，具体选择哪个（或者都不选择）是根据项目需求选择的，框架本身的差异并不大，基本都是如下模式
‘贰’ 分布式Web服务器架构
最开始，由于某些想法，于是在互联网上搭建了一个网站，这个时候甚至有可能主机都是租借的，但由于这篇文章我们只关注架构的演变历程，因此就假设这个时候已经是托管了一台主机，并且有一定的带宽了，这个时候由于网站具备了一定的特色，吸引了部分人访问，逐渐你发现系统的压力越来越高，响应速度越来越慢，而这个时候比较明显的是数据库和应用互相影响，应用出问题了，数据库也很容易出现问题，而数据库出问题的时候，应用也容易出问题，于是进入了第一步演变阶段：将应用和数据库从物理上分离，变成了两台机器，这个时候技术上没有什么新的要求，但你发现确实起到效果了，系统又恢复到以前的响应速度了，并且支撑住了更高的流量，并且不会因为数据库和应用形成互相的影响。
这一步架构演变对技术上的知识体系基本没有要求。
架构演变第二步：增加页面缓存
好景不长，随着访问的人越来越多，你发现响应速度又开始变慢了，查找原因，发现是访问数据库的操作太多，导致数据连接竞争激烈，所以响应变慢，但数据库连接又不能开太多，否则数据库机器压力会很高，因此考虑采用缓存机制来减少数据库连接资源的竞争和对数据库读的压力，这个时候首先也许会选择采用squid 等类似的机制来将系统中相对静态的页面（例如一两天才会有更新的页面）进行缓存（当然，也可以采用将页面静态化的方案），这样程序上可以不做修改，就能够很好的减少对webserver的压力以及减少数据库连接资源的竞争，OK，于是开始采用squid来做相对静态的页面的缓存。
前端页面缓存技术，例如squid，如想用好的话还得深入掌握下squid的实现方式以及缓存的失效算法等。
架构演变第三步：增加页面片段缓存
增加了squid做缓存后，整体系统的速度确实是提升了，webserver的压力也开始下降了，但随着访问量的增加，发现系统又开始变的有些慢了，在尝到了squid之类的动态缓存带来的好处后，开始想能不能让现在那些动态页面里相对静态的部分也缓存起来呢，因此考虑采用类似ESI之类的页面片段缓存策略，OK，于是开始采用ESI来做动态页面中相对静态的片段部分的缓存。
这一步涉及到了这些知识体系：
页面片段缓存技术，例如ESI等，想用好的话同样需要掌握ESI的实现方式等；
架构演变第四步：数据缓存
在采用ESI之类的技术再次提高了系统的缓存效果后，系统的压力确实进一步降低了，但同样，随着访问量的增加，系统还是开始变慢，经过查找，可能会发现系统中存在一些重复获取数据信息的地方，像获取用户信息等，这个时候开始考虑是不是可以将这些数据信息也缓存起来呢，于是将这些数据缓存到本地内存，改变完毕后，完全符合预期，系统的响应速度又恢复了，数据库的压力也再度降低了不少。
这一步涉及到了这些知识体系：
缓存技术，包括像Map数据结构、缓存算法、所选用的框架本身的实现机制等。
架构演变第五步： 增加webserver
好景不长，发现随着系统访问量的再度增加，webserver机器的压力在高峰期会上升到比较高，这个时候开始考虑增加一台webserver，这也是为了同时解决可用性的问题，避免单台的webserver down机的话就没法使用了，在做了这些考虑后，决定增加一台webserver，增加一台webserver时，会碰到一些问题，典型的有：
1、如何让访问分配到这两台机器上，这个时候通常会考虑的方案是Apache自带的负载均衡方案，或LVS这类的软件负载均衡方案；
2、如何保持状态信息的同步，例如用户session等，这个时候会考虑的方案有写入数据库、写入存储、cookie或同步session信息等机制等；
3、如何保持数据缓存信息的同步，例如之前缓存的用户数据等，这个时候通常会考虑的机制有缓存同步或分布式缓存；
4、如何让上传文件这些类似的功能继续正常，这个时候通常会考虑的机制是使用共享文件系统或存储等；
在解决了这些问题后，终于是把webserver增加为了两台，系统终于是又恢复到了以往的速度。
这一步涉及到了这些知识体系：
负载均衡技术（包括但不限于硬件负载均衡、软件负载均衡、负载算法、linux转发协议、所选用的技术的实现细节等）、主备技术（包括但不限于 ARP欺骗、linux heart-beat等）、状态信息或缓存同步技术（包括但不限于Cookie技术、UDP协议、状态信息广播、所选用的缓存同步技术的实现细节等）、共享文件技术（包括但不限于NFS等）、存储技术（包括但不限于存储设备等）。
架构演变第六步：分库
享受了一段时间的系统访问量高速增长的幸福后，发现系统又开始变慢了，这次又是什么状况呢，经过查找，发现数据库写入、更新的这些操作的部分数据库连接的资源竞争非常激烈，导致了系统变慢，这下怎么办呢，此时可选的方案有数据库集群和分库策略，集群方面像有些数据库支持的并不是很好，因此分库会成为比较普遍的策略，分库也就意味着要对原有程序进行修改，一通修改实现分库后，不错，目标达到了，系统恢复甚至速度比以前还快了。
这一步涉及到了这些知识体系：
这一步更多的是需要从业务上做合理的划分，以实现分库，具体技术细节上没有其他的要求；
但同时随着数据量的增大和分库的进行，在数据库的设计、调优以及维护上需要做的更好，因此对这些方面的技术还是提出了很高的要求的。
架构演变第七步：分表、DAL和分布式缓存
随着系统的不断运行，数据量开始大幅度增长，这个时候发现分库后查询仍然会有些慢，于是按照分库的思想开始做分表的工作，当然，这不可避免的会需要对程序进行一些修改，也许在这个时候就会发现应用自己要关心分库分表的规则等，还是有些复杂的，于是萌生能否增加一个通用的框架来实现分库分表的数据访问，这个在ebay的架构中对应的就是DAL，这个演变的过程相对而言需要花费较长的时间，当然，也有可能这个通用的框架会等到分表做完后才开始做，同时，在这个阶段可能会发现之前的缓存同步方案出现问题，因为数据量太大，导致现在不太可能将缓存存在本地，然后同步的方式，需要采用分布式缓存方案了，于是，又是一通考察和折磨，终于是将大量的数据缓存转移到分布式缓存上了。
这一步涉及到了这些知识体系：
分表更多的同样是业务上的划分，技术上涉及到的会有动态hash算法、consistent hash算法等；
DAL涉及到比较多的复杂技术，例如数据库连接的管理（超时、异常）、数据库操作的控制（超时、异常）、分库分表规则的封装等；
架构演变第八步：增加更多的webserver
在做完分库分表这些工作后，数据库上的压力已经降到比较低了，又开始过着每天看着访问量暴增的幸福生活了，突然有一天，发现系统的访问又开始有变慢的趋势了，这个时候首先查看数据库，压力一切正常，之后查看webserver，发现apache阻塞了很多的请求，而应用服务器对每个请求也是比较快的，看来是请求数太高导致需要排队等待，响应速度变慢，这还好办，一般来说，这个时候也会有些钱了，于是添加一些webserver服务器，在这个添加 webserver服务器的过程，有可能会出现几种挑战：
1、Apache的软负载或LVS软负载等无法承担巨大的web访问量（请求连接数、网络流量等）的调度了，这个时候如果经费允许的话，会采取的方案是购买硬件负载，例如F5、Netsclar、Athelon之类的，如经费不允许的话，会采取的方案是将应用从逻辑上做一定的分类，然后分散到不同的软负载集群中；
2、原有的一些状态信息同步、文件共享等方案可能会出现瓶颈，需要进行改进，也许这个时候会根据情况编写符合网站业务需求的分布式文件系统等；
在做完这些工作后，开始进入一个看似完美的无限伸缩的时代，当网站流量增加时，应对的解决方案就是不断的添加webserver。
这一步涉及到了这些知识体系：
到了这一步，随着机器数的不断增长、数据量的不断增长和对系统可用性的要求越来越高，这个时候要求对所采用的技术都要有更为深入的理解，并需要根据网站的需求来做更加定制性质的产品。
架构演变第九步：数据读写分离和廉价存储方案
突然有一天，发现这个完美的时代也要结束了，数据库的噩梦又一次出现在眼前了，由于添加的webserver太多了，导致数据库连接的资源还是不够用，而这个时候又已经分库分表了，开始分析数据库的压力状况，可能会发现数据库的读写比很高，这个时候通常会想到数据读写分离的方案，当然，这个方案要实现并不容易，另外，可能会发现一些数据存储在数据库上有些浪费，或者说过于占用数据库资源，因此在这个阶段可能会形成的架构演变是实现数据读写分离，同时编写一些更为廉价的存储方案，例如BigTable这种。
这一步涉及到了这些知识体系：
数据读写分离要求对数据库的复制、standby等策略有深入的掌握和理解，同时会要求具备自行实现的技术；
廉价存储方案要求对OS的文件存储有深入的掌握和理解，同时要求对采用的语言在文件这块的实现有深入的掌握。
架构演变第十步：进入大型分布式应用时代和廉价服务器群梦想时代
经过上面这个漫长而痛苦的过程，终于是再度迎来了完美的时代，不断的增加webserver就可以支撑越来越高的访问量了，对于大型网站而言，人气的重要毋庸置疑，随着人气的越来越高，各种各样的功能需求也开始爆发性的增长，这个时候突然发现，原来部署在webserver上的那个web应用已经非常庞大了，当多个团队都开始对其进行改动时，可真是相当的不方便，复用性也相当糟糕，基本是每个团队都做了或多或少重复的事情，而且部署和维护也是相当的麻烦，因为庞大的应用包在N台机器上复制、启动都需要耗费不少的时间，出问题的时候也不是很好查，另外一个更糟糕的状况是很有可能会出现某个应用上的bug就导致了全站都不可用，还有其他的像调优不好操作（因为机器上部署的应用什么都要做，根本就无法进行针对性的调优）等因素，根据这样的分析，开始痛下决心，将系统根据职责进行拆分，于是一个大型的分布式应用就诞生了，通常，这个步骤需要耗费相当长的时间，因为会碰到很多的挑战：
1、拆成分布式后需要提供一个高性能、稳定的通信框架，并且需要支持多种不同的通信和远程调用方式；
2、将一个庞大的应用拆分需要耗费很长的时间，需要进行业务的整理和系统依赖关系的控制等；
3、如何运维（依赖管理、运行状况管理、错误追踪、调优、监控和报警等）好这个庞大的分布式应用。
经过这一步，差不多系统的架构进入相对稳定的阶段，同时也能开始采用大量的廉价机器来支撑着巨大的访问量和数据量，结合这套架构以及这么多次演变过程吸取的经验来采用其他各种各样的方法来支撑着越来越高的访问量。
这一步涉及到了这些知识体系：
这一步涉及的知识体系非常的多，要求对通信、远程调用、消息机制等有深入的理解和掌握，要求的都是从理论、硬件级、操作系统级以及所采用的语言的实现都有清楚的理解。
运维这块涉及的知识体系也非常的多，多数情况下需要掌握分布式并行计算、报表、监控技术以及规则策略等等。
说起来确实不怎么费力，整个网站架构的经典演变过程都和上面比较的类似，当然，每步采取的方案，演变的步骤有可能有不同，另外，由于网站的业务不同，会有不同的专业技术的需求，这篇blog更多的是从架构的角度来讲解演变的过程，当然，其中还有很多的技术也未在此提及，像数据库集群、数据挖掘、搜索等，但在真实的演变过程中还会借助像提升硬件配置、网络环境、改造操作系统、CDN镜像等来支撑更大的流量，因此在真实的发展过程中还会有很多的不同，另外一个大型网站要做到的远远不仅仅上面这些，还有像安全、运维、运营、服务、存储等，要做好一个大型的网站真的很不容易
‘叁’ 什么是分布式感谢分享,百度能搜到的概念性的东西就不要贴了 java开发的web网站怎么实现分布式
我看了网络后的理解是：
集群：集群是同一个任务，由许多台服务器通过负载均衡来完成。
分布式：一个任务，拆分为多个子任务，由不同的服务器完成各自的结果并汇总。
比如有二十个算术题，集群负载均衡概念是让10个人每个人分1个或2个题，有的人学习很好，可能就给他分3道题，有的人学习差，就只给他分1个题。注意每个人分到的这些题都是完整的一道或多道题并没有拆分。把学习能力理解为服务器的处理能力就可以了。
有一个算术题，分布式的概念是，把这个题分成几个小问题，分给一堆人，这堆人每个人解决自己的小问题。
分布式利用集群概念是指：首先布置一层分布式网络，例如A节点处理乘法问题，B节点处理加法问题。那么A节点服务器或许会接收到大量的计算请求。例如例子中的现在有20个乘法题，那么A节点可以采用集群方式，把这20个乘法题负载均衡的方式分给同在A节点的其他服务器。这里有个点就是，A节点可以是一台服务器，也可是多台服务器。当是多台服务器处理同类请求的时候，显然就是分布式中某个节点利用了集群概念了。
这只是我自己的理解，如果不是的话还请路过大神指正。。。
关于你说的问题，我挑个我会的吧。运行同一个web程序，我认为这是集群概念而非分布式概念，如果每个节点运行一个web程序的一部分，例如A运行 数学计算 程序的 加法部分。B运行乘法部分，我认为这才算分布式概念。运行同一个web程序，显然可以同时接受大量请求，然后负载均衡给每一台服务器完整运行咯。
就我知道的，Dubbo框架就是一个分布式框架，也可以实现集群负载均衡。
‘肆’ websphere 分布式计算和架构是怎么实现的
介绍
分布式计算简单来说，是把一个大计算任务拆分成多个小计算任务分布到若干台机器上去计算，然后再进行结果汇总。 目的在于分析计算海量的数据，从雷达监测的海量历史信号中分析异常信号(外星文明)，淘宝双十一实时计算各地区的消费习惯等。
海量计算最开始的方案是提高单机计算性能，如大型机，后来由于数据的爆发式增长、单机性能却跟不上，才有分布式计算这种妥协方案。 因为计算一旦拆分，问题会变得非常复杂，像一致性、数据完整、通信、容灾、任务调度等问题也都来了。
举个例子，产品要求从数据库中100G的用户购买数据，分析出各地域的消费习惯金额等。 如果没什么时间要求，程序员小明就写个对应的业务处理服务程序，部署到服务器上，让它慢慢跑就是了，小明预计10个小时能处理完。 后面产品嫌太慢，让小明想办法加快到3个小时。
平常开发中类似的需求也很多，总结出来就是，数据量大、单机计算慢。 如果上Hadoop、storm之类成本较高、而且有点大才小用。 当然让老板买更好的服务器配置也是一种办法。
利用分片算法
小明作为一个有追求有理想的程序员，决定用介于单机计算和成熟计算框架的过度解决方案，这样成本和需求都能满足了。 分布式计算的核心在于计算任务拆分，如果数据能以水平拆分的方式，分布到5台机器上，每台机器只计算自身的1/5数据，这样即能在3小时内完成产品需求了。
如上所述，小明需要把这些数据按照一定维度进行划分。 按需求来看以用户ID划分最好，由于用户之间没有状态上的关联，所以也不需要事务性及二次迭代计算。 小明用简单的hash取模对id进行划分。
f(memberid) % 5 = ServerN
这样程序可以分别部署到5台机器上，然后程序按照配置只取对应余数的用户id，计算出结果并入库。 这种方式多机之间毫无关联，不需要进行通信，可以避免很多问题。 机器上的程序本身也不具备分布式的特性，它和单机一样，只计算自身获取到的数据即可，所以如果某台机器上程序崩溃的话，处理方式和单机一样，比如记录下处理进度，下次从当前进度继续进行后续计算。
利用消息队列
使用分片方式相对比较简单，但有如下不足之处。
它不具有负载均衡的能力，如果某台机器配置稍好点，它可能最先计算完，然后空闲等待着。也有可能是某些用户行为数据比较少，导致计算比较快完成。
还有一个弊端就是每台机器上需要手动更改对应的配置， 这样的话多台机器上的程序不是完全一样的，这样可以用远程配置动态修改的办法来解决。
小明这种方式引入了个第三方，消息队列。 小明先用一个单独的程序把用户信息推送到消息队列里去，然后各台机器分别取消费这个队列。 于是就有了3个角色：
推送消息的，简称Master。
消息队列，这里以Rabbitmq为例。
各个处理程序，简称Worker或Slave都行。
虽然仅仅引入了个第三方，但它已经具备了分布式计算的很多特性。
计算任务分发。 Master把需要计算的用户数据，不断的推送消息队列。
程序一致性。 Worker订阅相同的消息队列即可，无需更改程序代码。
任意扩容。 由于程序完全一样，意味着如果想要加快速度，重复部署一份程序到新机器即可。 当然这是理论上的，实际当中会受限于消息队列、数据库存储等。
容灾性。 如果5台中某一台程序挂了也不影响，利用Rabbitmq的消息确认机制，机器崩溃时正在计算的那一条数据会在超时，在其他节点上进行消费处理。
Hadoop简介
Hadoop介绍已经相当多了，这里简述下比如:”Hadoop是一套海量数据计算存储的基础平台架构”，分析下这句话。
其中计算指的是MapRece，这是做分布式计算用的。
存储指的是HDFS，基于此上层的有HBase、Hive，用来做数据存储用的。
平台，指可以给多个用户使用，比如小明有一计算需求，他只需要按照对应的接口编写业务逻辑即可，然后把程序以包的形式发布到平台上，平台进行分配调度计算等。 而上面小明的分布式计算设计只能给自己使用，如果另外有小华要使用就需要重新写一份，然后单独部署，申请机器等。Hadoop最大的优势之一就在于提供了一套这样的完整解决方案。
下面找了介绍Hadoop的概览图，跟小明的设计做对比下:
图中“大数据计算任务” 对应小明的100G用户数据的计算任务。
”任务划分“ 对应Master和消息队列。
“子任务” 对应Worker的业务逻辑。
”结果合并“ 对应把每个worker的计算结果入库。
“计算结果” 对应入库的用户消费习惯数据。
PS：为了方便描述，把小明设计的分布式计算，叫做小和尚。
MapRece
由于MapRece计算输入和输出都是基于HDFS文件，所以大多数公司的做法是把mysql或sqlserver的数据导入到HDFS，计算完后再导出到常规的数据库中，这是MapRece不够灵活的地方之一。 MapRece优势在于提供了比较简单的分布式计算编程模型，使开发此类程序变得非常简单，像之前的MPI编程就相当复杂。
狭隘的来讲，MapRece是把计算任务给规范化了，它可以等同于小和尚中Worker的业务逻辑部分。 MapRece把业务逻辑给拆分成2个大部分，Map和Rece，可以先在Map部分把任务计算一半后，扔给Rece部分继续后面的计算。 当然在Map部分把计算任务全做完也是可以的。 关于Maprece实现细节部分不多解释，有兴趣的同学可以查相关资料或看下楼主之前的C#模拟实现的博客【探索C#之微型MapRece】。
如果把小明产品经理的需求放到Hadoop来做，其处理流程大致如下：
把100G数据导入到HDFS
按照Maprece的接口编写处理逻辑，分Map、Rece两部分。
把程序包提交到Maprece平台上，存储在HDFS里。
平台中有个叫Jobtracker进程的角色进行分发任务。 这个类似小和尚的Master负载调度管理。
如果有5台机器进行计算的话，就会提前运行5个叫TaskTracker的slave进程。 这类似小和尚worker的分离版，平台把程序和业务逻辑进行分离了， 简单来说就是在机器上运行个独立进程，它能动态加载、执行jar或dll的业务逻辑代码。
Jobtracker把任务分发到TaskTracker后，TaskTracker把开始动态加载jar包，创建个独立进程执行Map部分，然后把结果写入到HDFS上。
如果有Rece部分，TaskTracker会创建个独立进程把Map输出的HDFS文件，通过RPC方式远程拉取到本地，拉取成功后，Rece开始计算后续任务。
Rece再把结果写入到HDFS中
从HDFS中把结果导出。
这样一看好像是把简单的计算任务给复杂化了，其实如果只有几台计算任务的话，使用Maprece确实是杀鸡用牛刀了。 如果有TB、PB级别的数据、跑在成百上千台计算节点上，Maprece的优势才会体现出来。 其计算框架图架构如下：
离线计算
通常称Maprece及小和尚这种计算为离线计算，因为它对已经持久化的文件数据进行计算，不能实时响应。 还有个原因就是它的处理速度比较慢，它的输入和输出源都是基于HDFS设计，如果数据不是一开始就写入到HDFS上，就会涉及到数据导入导出，这部分相对耗费时间。 而且它的数据流动是基于文件系统的，Map部分输出的数据不是直接传送到Rece部分，而是先写入HDFS再进行传送。
处理速度慢也是Maprece的不足之处，促使了后面实时计算的诞生。
另外个缺点是Maprece的计算任务流比较单一，它只有Map、Rece两部分。 简单的可以只写一部分逻辑来解决，如果想拆分成多个部分，如逻辑A、逻辑B、逻辑C等， 而且一部分计算逻辑依赖上一次计算结果的话，MapRece处理起来就比较困难了。 像storm框架解决此类问题的方案，也称为流式计算，下一章继续补充。
‘伍’ Python 有哪些好的 Web 框架
以下是伯乐在线从GitHub中整理出的15个最受欢迎的Python开源框架。这些框架包括事件I/O，OLAP，Web开发，高性能网络通信，测试，爬虫等。
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编写的，轻量级的，简单轻巧，并且使用起来非常的方便。
‘陆’ 开发基于Java的分布式WEB应用，你需要什么样的框架支持讨论第4页:
Agrael 写道andot 写道Agrael 写道大家一直说EJB重，我不解，EJB到了3.0还重？我看到帖子都只说EJB重，却不说重在什么地方。就我个人而言，EJB2.X不谈，EJB3.x绝对不重，反而有向轻量发展的趋势。可能是EJB最初给人留下的印象太差了，以至于现在没人去关注新的EJB了。我觉得要推广新的轻量级的EJB，改个名字可能是个好办法。不过在国外EJB3.x却很流行。但是在中国却很少有人用。不仅在国外，大公司对EJB非常重视，程度要高于SSH之类的。
‘柒’ 大数据技术与应用是学什么的
大数据技术与应用主要学：
面向对象程序设计、Hadoop实用技术、数据挖掘、机器学习、数据统计分析、高等数学、Python编程、JAVA编程、数据库技术、Web开发、Linux操作系统、大数据平台搭建及运维、大数据应用开发、可视化设计与开发等。