㈠ php怎么处理高并发
以下内容转载自徐汉彬大牛的博客亿级Web系统搭建——单机到分布式集群
当一个Web系统从日访问量10万逐步增长到1000万，甚至超过1亿的过程中，Web系统承受的压力会越来越大，在这个过程中，我们会遇到很多的问题。为了解决这些性能压力带来问题，我们需要在Web系统架构层面搭建多个层次的缓存机制。在不同的压力阶段，我们会遇到不同的问题，通过搭建不同的服务和架构来解决。
Web负载均衡
Web负载均衡（Load Balancing），简单地说就是给我们的服务器集群分配“工作任务”，而采用恰当的分配方式，对于保护处于后端的Web服务器来说，非常重要。
负载均衡的策略有很多，我们从简单的讲起哈。
1.HTTP重定向
当用户发来请求的时候，Web服务器通过修改HTTP响应头中的Location标记来返回一个新的url，然后浏览器再继续请求这个新url，实际上就是页面重定向。通过重定向，来达到“负载均衡”的目标。例如，我们在下载PHP源码包的时候，点击下载链接时，为了解决不同国家和地域下载速度的问题，它会返回一个离我们近的下载地址。重定向的HTTP返回码是302
这个重定向非常容易实现，并且可以自定义各种策略。但是，它在大规模访问量下，性能不佳。而且，给用户的体验也不好，实际请求发生重定向，增加了网络延时。
2. 反向代理负载均衡
反向代理服务的核心工作主要是转发HTTP请求，扮演了浏览器端和后台Web服务器中转的角色。因为它工作在HTTP层（应用层），也就是网络七层结构中的第七层，因此也被称为“七层负载均衡”。可以做反向代理的软件很多，比较常见的一种是Nginx。
Nginx是一种非常灵活的反向代理软件，可以自由定制化转发策略，分配服务器流量的权重等。反向代理中，常见的一个问题，就是Web服务器存储的session数据，因为一般负载均衡的策略都是随机分配请求的。同一个登录用户的请求，无法保证一定分配到相同的Web机器上，会导致无法找到session的问题。
解决方案主要有两种：
1.配置反向代理的转发规则，让同一个用户的请求一定落到同一台机器上（通过分析cookie），复杂的转发规则将会消耗更多的CPU，也增加了代理服务器的负担。
2.将session这类的信息，专门用某个独立服务来存储，例如redis/memchache，这个方案是比较推荐的。
反向代理服务，也是可以开启缓存的，如果开启了，会增加反向代理的负担，需要谨慎使用。这种负载均衡策略实现和部署非常简单，而且性能表现也比较好。但是，它有“单点故障”的问题，如果挂了，会带来很多的麻烦。而且，到了后期Web服务器继续增加，它本身可能成为系统的瓶颈。
3. IP负载均衡
IP负载均衡服务是工作在网络层（修改IP）和传输层（修改端口，第四层），比起工作在应用层（第七层）性能要高出非常多。原理是，他是对IP层的数据包的IP地址和端口信息进行修改，达到负载均衡的目的。这种方式，也被称为“四层负载均衡”。常见的负载均衡方式，是LVS（Linux Virtual Server，Linux虚拟服务），通过IPVS（IP Virtual Server，IP虚拟服务）来实现。
在负载均衡服务器收到客户端的IP包的时候，会修改IP包的目标IP地址或端口，然后原封不动地投递到内部网络中，数据包会流入到实际Web服务器。实际服务器处理完成后，又会将数据包投递回给负载均衡服务器，它再修改目标IP地址为用户IP地址，最终回到客户端。
上述的方式叫LVS-NAT，除此之外，还有LVS-RD（直接路由），LVS-TUN（IP隧道），三者之间都属于LVS的方式，但是有一定的区别，篇幅问题，不赘叙。
IP负载均衡的性能要高出Nginx的反向代理很多，它只处理到传输层为止的数据包，并不做进一步的组包，然后直接转发给实际服务器。不过，它的配置和搭建比较复杂。
4. DNS负载均衡
DNS（Domain Name System）负责域名解析的服务，域名url实际上是服务器的别名，实际映射是一个IP地址，解析过程，就是DNS完成域名到IP的映射。而一个域名是可以配置成对应多个IP的。因此，DNS也就可以作为负载均衡服务。
这种负载均衡策略，配置简单，性能极佳。但是，不能自由定义规则，而且，变更被映射的IP或者机器故障时很麻烦，还存在DNS生效延迟的问题。
5. DNS/GSLB负载均衡
我们常用的CDN（Content Delivery Network，内容分发网络）实现方式，其实就是在同一个域名映射为多IP的基础上更进一步，通过GSLB（Global Server Load Balance，全局负载均衡）按照指定规则映射域名的IP。一般情况下都是按照地理位置，将离用户近的IP返回给用户，减少网络传输中的路由节点之间的跳跃消耗。
“向上寻找”，实际过程是LDNS（Local DNS）先向根域名服务（Root Name Server）获取到顶级根的Name Server（例如.com的），然后得到指定域名的授权DNS，然后再获得实际服务器IP。
CDN在Web系统中，一般情况下是用来解决大小较大的静态资源（html/Js/Css/图片等）的加载问题，让这些比较依赖网络下载的内容，尽可能离用户更近，提升用户体验。
例如，我访问了一张imgcache.gtimg.cn上的图片（腾讯的自建CDN，不使用qq.com域名的原因是防止http请求的时候，带上了多余的cookie信息），我获得的IP是183.60.217.90。
这种方式，和前面的DNS负载均衡一样，不仅性能极佳，而且支持配置多种策略。但是，搭建和维护成本非常高。互联网一线公司，会自建CDN服务，中小型公司一般使用第三方提供的CDN。
Web系统的缓存机制的建立和优化
刚刚我们讲完了Web系统的外部网络环境，现在我们开始关注我们Web系统自身的性能问题。我们的Web站点随着访问量的上升，会遇到很多的挑战，解决这些问题不仅仅是扩容机器这么简单，建立和使用合适的缓存机制才是根本。
最开始，我们的Web系统架构可能是这样的，每个环节，都可能只有1台机器。
我们从最根本的数据存储开始看哈。
一、 MySQL数据库内部缓存使用
MySQL的缓存机制，就从先从MySQL内部开始，下面的内容将以最常见的InnoDB存储引擎为主。
1. 建立恰当的索引
最简单的是建立索引，索引在表数据比较大的时候，起到快速检索数据的作用，但是成本也是有的。首先，占用了一定的磁盘空间，其中组合索引最突出，使用需要谨慎，它产生的索引甚至会比源数据更大。其次，建立索引之后的数据insert/update/delete等操作，因为需要更新原来的索引，耗时会增加。当然，实际上我们的系统从总体来说，是以select查询操作居多，因此，索引的使用仍然对系统性能有大幅提升的作用。
2. 数据库连接线程池缓存
如果，每一个数据库操作请求都需要创建和销毁连接的话，对数据库来说，无疑也是一种巨大的开销。为了减少这类型的开销，可以在MySQL中配置thread_cache_size来表示保留多少线程用于复用。线程不够的时候，再创建，空闲过多的时候，则销毁。
其实，还有更为激进一点的做法，使用pconnect（数据库长连接），线程一旦创建在很长时间内都保持着。但是，在访问量比较大，机器比较多的情况下，这种用法很可能会导致“数据库连接数耗尽”，因为建立连接并不回收，最终达到数据库的max_connections（最大连接数）。因此，长连接的用法通常需要在CGI和MySQL之间实现一个“连接池”服务，控制CGI机器“盲目”创建连接数。
建立数据库连接池服务，有很多实现的方式，PHP的话，我推荐使用swoole（PHP的一个网络通讯拓展）来实现。
3. Innodb缓存设置（innodb_buffer_pool_size）
innodb_buffer_pool_size这是个用来保存索引和数据的内存缓存区，如果机器是MySQL独占的机器，一般推荐为机器物理内存的80%。在取表数据的场景中，它可以减少磁盘IO。一般来说，这个值设置越大，cache命中率会越高。
4. 分库/分表/分区。
MySQL数据库表一般承受数据量在百万级别，再往上增长，各项性能将会出现大幅度下降，因此，当我们预见数据量会超过这个量级的时候，建议进行分库/分表/分区等操作。最好的做法，是服务在搭建之初就设计为分库分表的存储模式，从根本上杜绝中后期的风险。不过，会牺牲一些便利性，例如列表式的查询，同时，也增加了维护的复杂度。不过，到了数据量千万级别或者以上的时候，我们会发现，它们都是值得的。
二、 MySQL数据库多台服务搭建
1台MySQL机器，实际上是高风险的单点，因为如果它挂了，我们Web服务就不可用了。而且，随着Web系统访问量继续增加，终于有一天，我们发现1台MySQL服务器无法支撑下去，我们开始需要使用更多的MySQL机器。当引入多台MySQL机器的时候，很多新的问题又将产生。
1. 建立MySQL主从，从库作为备份
这种做法纯粹为了解决“单点故障”的问题，在主库出故障的时候，切换到从库。不过，这种做法实际上有点浪费资源，因为从库实际上被闲着了。
2. MySQL读写分离，主库写，从库读。
两台数据库做读写分离，主库负责写入类的操作，从库负责读的操作。并且，如果主库发生故障，仍然不影响读的操作，同时也可以将全部读写都临时切换到从库中（需要注意流量，可能会因为流量过大，把从库也拖垮）。
3. 主主互备。
两台MySQL之间互为彼此的从库，同时又是主库。这种方案，既做到了访问量的压力分流，同时也解决了“单点故障”问题。任何一台故障，都还有另外一套可供使用的服务。
不过，这种方案，只能用在两台机器的场景。如果业务拓展还是很快的话，可以选择将业务分离，建立多个主主互备。
三、 MySQL数据库机器之间的数据同步
每当我们解决一个问题，新的问题必然诞生在旧的解决方案上。当我们有多台MySQL，在业务高峰期，很可能出现两个库之间的数据有延迟的场景。并且，网络和机器负载等，也会影响数据同步的延迟。我们曾经遇到过，在日访问量接近1亿的特殊场景下，出现，从库数据需要很多天才能同步追上主库的数据。这种场景下，从库基本失去效用了。
于是，解决同步问题，就是我们下一步需要关注的点。
1. MySQL自带多线程同步
MySQL5.6开始支持主库和从库数据同步，走多线程。但是，限制也是比较明显的，只能以库为单位。MySQL数据同步是通过binlog日志，主库写入到binlog日志的操作，是具有顺序的，尤其当SQL操作中含有对于表结构的修改等操作，对于后续的SQL语句操作是有影响的。因此，从库同步数据，必须走单进程。
2. 自己实现解析binlog，多线程写入。
以数据库的表为单位，解析binlog多张表同时做数据同步。这样做的话，的确能够加快数据同步的效率，但是，如果表和表之间存在结构关系或者数据依赖的话，则同样存在写入顺序的问题。这种方式，可用于一些比较稳定并且相对独立的数据表。
国内一线互联网公司，大部分都是通过这种方式，来加快数据同步效率。还有更为激进的做法，是直接解析binlog，忽略以表为单位，直接写入。但是这种做法，实现复杂，使用范围就更受到限制，只能用于一些场景特殊的数据库中（没有表结构变更，表和表之间没有数据依赖等特殊表）。
四、 在Web服务器和数据库之间建立缓存
实际上，解决大访问量的问题，不能仅仅着眼于数据库层面。根据“二八定律”，80%的请求只关注在20%的热点数据上。因此，我们应该建立Web服务器和数据库之间的缓存机制。这种机制，可以用磁盘作为缓存，也可以用内存缓存的方式。通过它们，将大部分的热点数据查询，阻挡在数据库之前。
1. 页面静态化
用户访问网站的某个页面，页面上的大部分内容在很长一段时间内，可能都是没有变化的。例如一篇新闻报道，一旦发布几乎是不会修改内容的。这样的话，通过CGI生成的静态html页面缓存到Web服务器的磁盘本地。除了第一次，是通过动态CGI查询数据库获取之外，之后都直接将本地磁盘文件返回给用户。
在Web系统规模比较小的时候，这种做法看似完美。但是，一旦Web系统规模变大，例如当我有100台的Web服务器的时候。那样这些磁盘文件，将会有100份，这个是资源浪费，也不好维护。这个时候有人会想，可以集中一台服务器存起来，呵呵，不如看看下面一种缓存方式吧，它就是这样做的。
2. 单台内存缓存
通过页面静态化的例子中，我们可以知道将“缓存”搭建在Web机器本机是不好维护的，会带来更多问题（实际上，通过PHP的apc拓展，可通过Key/value操作Web服务器的本机内存）。因此，我们选择搭建的内存缓存服务，也必须是一个独立的服务。
内存缓存的选择，主要有redis/memcache。从性能上说，两者差别不大，从功能丰富程度上说，Redis更胜一筹。
3. 内存缓存集群
当我们搭建单台内存缓存完毕，我们又会面临单点故障的问题，因此，我们必须将它变成一个集群。简单的做法，是给他增加一个slave作为备份机器。但是，如果请求量真的很多，我们发现cache命中率不高，需要更多的机器内存呢？因此，我们更建议将它配置成一个集群。例如，类似redis cluster。
Redis cluster集群内的Redis互为多组主从，同时每个节点都可以接受请求，在拓展集群的时候比较方便。客户端可以向任意一个节点发送请求，如果是它的“负责”的内容，则直接返回内容。否则，查找实际负责Redis节点，然后将地址告知客户端，客户端重新请求。
对于使用缓存服务的客户端来说，这一切是透明的。
内存缓存服务在切换的时候，是有一定风险的。从A集群切换到B集群的过程中，必须保证B集群提前做好“预热”（B集群的内存中的热点数据，应该尽量与A集群相同，否则，切换的一瞬间大量请求内容，在B集群的内存缓存中查找不到，流量直接冲击后端的数据库服务，很可能导致数据库宕机）。
4. 减少数据库“写”
上面的机制，都实现减少数据库的“读”的操作，但是，写的操作也是一个大的压力。写的操作，虽然无法减少，但是可以通过合并请求，来起到减轻压力的效果。这个时候，我们就需要在内存缓存集群和数据库集群之间，建立一个修改同步机制。
先将修改请求生效在cache中，让外界查询显示正常，然后将这些sql修改放入到一个队列中存储起来，队列满或者每隔一段时间，合并为一个请求到数据库中更新数据库。
除了上述通过改变系统架构的方式提升写的性能外，MySQL本身也可以通过配置参数innodb_flush_log_at_trx_commit来调整写入磁盘的策略。如果机器成本允许，从硬件层面解决问题，可以选择老一点的RAID（Rendant Arrays of independent Disks，磁盘列阵）或者比较新的SSD（Solid State Drives，固态硬盘）。
5. NoSQL存储
不管数据库的读还是写，当流量再进一步上涨，终会达到“人力有穷时”的场景。继续加机器的成本比较高，并且不一定可以真正解决问题的时候。这个时候，部分核心数据，就可以考虑使用NoSQL的数据库。NoSQL存储，大部分都是采用key-value的方式，这里比较推荐使用上面介绍过Redis，Redis本身是一个内存cache，同时也可以当做一个存储来使用，让它直接将数据落地到磁盘。
这样的话，我们就将数据库中某些被频繁读写的数据，分离出来，放在我们新搭建的Redis存储集群中，又进一步减轻原来MySQL数据库的压力，同时因为Redis本身是个内存级别的Cache，读写的性能都会大幅度提升。
国内一线互联网公司，架构上采用的解决方案很多是类似于上述方案，不过，使用的cache服务却不一定是Redis，他们会有更丰富的其他选择，甚至根据自身业务特点开发出自己的NoSQL服务。
6. 空节点查询问题
当我们搭建完前面所说的全部服务，认为Web系统已经很强的时候。我们还是那句话，新的问题还是会来的。空节点查询，是指那些数据库中根本不存在的数据请求。例如，我请求查询一个不存在人员信息，系统会从各级缓存逐级查找，最后查到到数据库本身，然后才得出查找不到的结论，返回给前端。因为各级cache对它无效，这个请求是非常消耗系统资源的，而如果大量的空节点查询，是可以冲击到系统服务的。
在我曾经的工作经历中，曾深受其害。因此，为了维护Web系统的稳定性，设计适当的空节点过滤机制，非常有必要。
我们当时采用的方式，就是设计一张简单的记录映射表。将存在的记录存储起来，放入到一台内存cache中，这样的话，如果还有空节点查询，则在缓存这一层就被阻挡了。
异地部署（地理分布式）
完成了上述架构建设之后，我们的系统是否就已经足够强大了呢？答案当然是否定的哈，优化是无极限的。Web系统虽然表面上看，似乎比较强大了，但是给予用户的体验却不一定是最好的。因为东北的同学，访问深圳的一个网站服务，他还是会感到一些网络距离上的慢。这个时候，我们就需要做异地部署，让Web系统离用户更近。
一、 核心集中与节点分散
有玩过大型网游的同学都会知道，网游是有很多个区的，一般都是按照地域来分，例如广东专区，北京专区。如果一个在广东的玩家，去北京专区玩，那么他会感觉明显比在广东专区卡。实际上，这些大区的名称就已经说明了，它的服务器所在地，所以，广东的玩家去连接地处北京的服务器，网络当然会比较慢。
当一个系统和服务足够大的时候，就必须开始考虑异地部署的问题了。让你的服务，尽可能离用户更近。我们前面已经提到了Web的静态资源，可以存放在CDN上，然后通过DNS/GSLB的方式，让静态资源的分散“全国各地”。但是，CDN只解决的静态资源的问题，没有解决后端庞大的系统服务还只集中在某个固定城市的问题。
这个时候，异地部署就开始了。异地部署一般遵循：核心集中，节点分散。
·核心集中：实际部署过程中，总有一部分的数据和服务存在不可部署多套，或者部署多套成本巨大。而对于这些服务和数据，就仍然维持一套，而部署地点选择一个地域比较中心的地方，通过网络内部专线来和各个节点通讯。
·节点分散：将一些服务部署为多套，分布在各个城市节点，让用户请求尽可能选择近的节点访问服务。
例如，我们选择在上海部署为核心节点，北京，深圳，武汉，上海为分散节点（上海自己本身也是一个分散节点）。我们的服务架构如图：
需要补充一下的是，上图中上海节点和核心节点是同处于一个机房的，其他分散节点各自独立机房。
国内有很多大型网游，都是大致遵循上述架构。它们会把数据量不大的用户核心账号等放在核心节点，而大部分的网游数据，例如装备、任务等数据和服务放在地区节点里。当然，核心节点和地域节点之间，也有缓存机制。
二、 节点容灾和过载保护
节点容灾是指，某个节点如果发生故障时，我们需要建立一个机制去保证服务仍然可用。毫无疑问，这里比较常见的容灾方式，是切换到附近城市节点。假如系统的天津节点发生故障，那么我们就将网络流量切换到附近的北京节点上。考虑到负载均衡，可能需要同时将流量切换到附近的几个地域节点。另一方面，核心节点自身也是需要自己做好容灾和备份的，核心节点一旦故障，就会影响全国服务。
过载保护，指的是一个节点已经达到最大容量，无法继续接接受更多请求了，系统必须有一个保护的机制。一个服务已经满负载，还继续接受新的请求，结果很可能就是宕机，影响整个节点的服务，为了至少保障大部分用户的正常使用，过载保护是必要的。
解决过载保护，一般2个方向：
·拒绝服务，检测到满负载之后，就不再接受新的连接请求。例如网游登入中的排队。
·分流到其他节点。这种的话，系统实现更为复杂，又涉及到负载均衡的问题。
小结
Web系统会随着访问规模的增长，渐渐地从1台服务器可以满足需求，一直成长为“庞然大物”的大集群。而这个Web系统变大的过程，实际上就是我们解决问题的过程。在不同的阶段，解决不同的问题，而新的问题又诞生在旧的解决方案之上。
系统的优化是没有极限的，软件和系统架构也一直在快速发展，新的方案解决了老的问题，同时也带来新的挑战。
㈡ 大数据技术包括哪些
想要成为炙手可热的大数据技术人才，这些大数据的核心技术一定要知晓！
一、大数据基础阶段
大数据基础阶段需掌握的技术有：Linux、Docker、KVM、MySQL基础、Oracle基础、MongoDB、redis以及hadoop maprece hdfs yarn等。
1、Linux命令
对于大数据开发通常是在Linux环境下进行的，相比Linux操作系统，Windows操作系统是封闭的操作系统，开源的大数据软件很受限制，因此，想从事大数据开发相关工作，还需掌握Linux基础操作命令
2、 Redis
Redis是一个key-value存储系统，其出现很大程度补偿了memcached这类key/value存储的不足，在部分场合可以对关系数据库起到很好的补充作用，它提供了Java，C/C++，C#，PHP，JavaScript，Perl，Object-C，Python，Ruby，Erlang等客户端，使用很方便，大数据开发需掌握Redis的安装、配置及相关使用方法。
二、大数据存储阶段
大数据存储阶段需掌握的技术有：hbase、hive、sqoop等。
1、HBase
HBase是一个分布式的、面向列的开源数据库，它不同于一般的关系数据库，更适合于非结构化数据存储的数据库，是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，大数据开发需掌握HBase基础知识、应用、架构以及高级用法等。
2、Hive
Hive是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供简单的sql查询功能，可以将sql语句转换为MapRece任务进行运行，十分适合数据仓库的统计分析。对于Hive需掌握其安装、应用及高级操作等。
三、大数据架构设计阶段
大数据架构设计阶段需掌握的技术有：Flume分布式、Zookeeper、Kafka等。
1、Kafka
Kafka是一种高吞吐量的分布式发布订阅消息系统，其在大数据开发应用上的目的是通过Hadoop的并行加载机制来统一线上和离线的消息处理，也是为了通过集群来提供实时的消息。大数据开发需掌握Kafka架构原理及各组件的作用和使用方法及相关功能的实现！
2、Flume
Flume是一款高可用、高可靠、分布式的海量日志采集、聚合和传输的系统，Flume支持在日志系统中定制各类数据发送方，用于收集数据;同时，Flume提供对数据进行简单处理，并写到各种数据接受方(可定制)的能力。大数据开发需掌握其安装、配置以及相关使用方法。
3、ZooKeeper
ZooKeeper是Hadoop和Hbase的重要组件，是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组件服务等，在大数据开发中要掌握ZooKeeper的常用命令及功能的实现方法。
四、大数据实时计算阶段
大数据实时计算阶段需掌握的技术有：Mahout、Spark、storm。
1、Spark
Spark是专为大规模数据处理而设计的快速通用的计算引擎，其提供了一个全面、统一的框架用于管理各种不同性质的数据集和数据源的大数据处理的需求，大数据开发需掌握Spark基础、SparkJob、Spark RDD、spark job部署与资源分配、Spark shuffle、Spark内存管理、Spark广播变量、Spark SQL、Spark Streaming以及Spark ML等相关知识。
2、storm
Storm为分布式实时计算提供了一组通用原语，可被用于“流处理”之中，实时处理消息并更新数据库。这是管理队列及工作者集群的另一种方式。Storm可以方便地在一个计算机集群中编写与扩展复杂的实时计算，Storm用于实时处理，就好比 Hadoop 用于批处理。Storm保证每个消息都会得到处理，而且它很快——在一个小集群中，每秒可以处理数以百万计的消息。
五、大数据数据采集阶段
大数据数据采集阶段需掌握的技术有：Python、Scala。
1、Python与数据分析
Python是面向对象的编程语言，拥有丰富的库，使用简单，应用广泛，在大数据领域也有所应用，主要可用于数据采集、数据分析以及数据可视化等，因此，大数据开发需学习一定的Python知识。
2、Scala
Scala是一门多范式的编程语言，大数据开发重要框架Spark是采用Scala语言设计的，想要学好Spark框架，拥有Scala基础是必不可少的，因此，大数据开发需掌握Scala编程基础知识！
以上只是一些简单的大数据核心技术总结，比较零散，想要学习大数据的同学，还是要按照一定到的技术路线图学习！
㈢ 门户网站需要什么类型的服务器
选择云主机（云服务器）和选择其他主机的方法类似，要选择合适的云主机就需要对自己的网站情况以及云主机的各项配置参数有一定了解，具体如下：
首先是网站的情况：
比如网站是静态还是动态为主，使用的什么的网站程序，对运行环境有何要求，是否需要配置特定的环境，这将影响到操作系统、存储模式的选择。
网站的日均访问人数和平均同时在线人数有多少，这将影响到CPU、内存、带宽等选择。
网站目前的数据有多大，未来是否会快速增加，这将影响到硬盘的选择。
网站是面向全国用户还是本地用户，这将影响到机房线路的选择。
在确定网站情况之后可以结合云主机的各项配置参数进行估算选择：
CPU：CPU代表主机的运算能力，如果网站流量较大，动态页面比较多，建议选择2核以上CPU。
2.内存：内存也是决定网站打开速度的重要因素，内存越大，可用缓存越大，打开速度也就越快，windows操作系统不支持选择512MB内存。
3.硬盘：硬盘的大小要根据网站的大小来决定，在选择时应该考虑到剩余空间。另外硬盘的I/O读取速度直接决定文件读取的快慢，新麦互联云主机硬盘的读取速度比其他网站快很多，一般情况下都够用。
4.带宽：云主机没有流量限制，所以主要考虑带宽。带宽是一个网站打开速度的直接体现，带宽越大，访问的时候，打开速度就越快。访问人数较多的网站，建议选择大的带宽。
5.操作系统：操作系统的选择和个人的熟悉情况和网站具体情况有关，对哪种操作系统比较了解就选择哪种操作系统，另外windows系统对asp程序支持较好，不过占用内存较多，而Linux系统对php程序支持较好，更省内存，并且有的程序可能只支持某个操作系统。
6.机房线路：线路选择合适的机房。
7.存储模式：分布式存储数据保留四份，而SSD固态硬盘适合对I/O读取速度有更高要求的用户。
如果还是不能确定选择何种配置，可以先购买一个标准配置运行一段时间进行观察，如果发现配置不够可以随时升级。
西部数码一直是全国10强，这两年每年的排名都在上升，现在全国3强吧，服务可以说是全国最好的，云服务器都可以自由升级，稳定性和速度也不错，新麦互联是西部数码的代理商，就像是海尔、美的的代理商似的，价格都比官方便宜，新麦互联的价格是西部数码的8折，而且享受新麦互联与西部数码的双重售后服务，可以说在代理处开通云服务器，服务只会加倍的，我很喜欢新麦互联的双线企业型虚拟主机和智能多线云服务器性价比还高。
㈣ php mysql分布式数据库如何实现
当前做分布式的厂商有几家，我知道比较出名的有“华为云分布式数据库DDM”和“阿里云分布式数据库”，感兴趣可以自行搜素了解下。
分布式数据库的几点概念可以了解一下。
数据分库：
以表为单位，把原有数据库切分成多个数据库。切分后不同的表存储在不同的数据库上。
以表中的数据行记录为单位，把原有逻辑数据库切分成多个物理数据库分片，表数据记录分布存储在各个分片上。
路由分发：
在分布式数据库中，路由的作用即将SQL语句进行解析，并转发到正确的分片上，保证SQL执行后得到正确的结果，并且节约QPS资源。
读写分离：
数据库中对计算和缓存资源消耗较多的往往是密集或复杂的SQL查询。当系统资源被查询语句消耗，反过来会影响数据写入操作，进而导致数据库整体性能下降，响应缓慢。因此，当数据库CPU和内存资源占用居高不下，且读写比例较高时，可以为数据库添加只读数据库。
㈤ 大型的PHP应用，通常使用什么应用做消息队列
一、消息队列概述x0dx0a消息队列中间件是分布式系统中重要的组件，主要解决应用耦合，异步消息，流量削锋等问题。实现高性能，高可用，可伸缩和最终一致性架构。是大型分布式系统不可缺少的中间件。x0dx0a目前在生产环境，使用较多的消息队列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ等。x0dx0a二、消息队列应用场景x0dx0a以下介绍消息队列在实际应用中常用的使用场景。异步处理，应用解耦，流量削锋和消息通讯四个场景。x0dx0a2.1异步处理x0dx0a场景说明：用户注册后，需要发注册邮件和注册短信。传统的做法有两种1.串行的方式；2.并行方式。x0dx0a（1）串行方式：将注册信息写入数据库成功后，发送注册邮件，再发送注册短信。以上三个任务全部完成后，返回给客户端。（架构KKQ：466097527，欢迎加入）x0dx0a（2）并行方式：将注册信息写入数据库成功后，发送注册邮件的同时，发送注册短信。以上三个任务完成后，返回给客户端。与串行的差别是，并行的方式可以提高处理的时间。x0dx0a假设三个业务节点每个使用50毫秒钟，不考虑网络等其他开销，则串行方式的时间是150毫秒，并行的时间可能是100毫秒。x0dx0a因为CPU在单位时间内处理的请求数是一定的，假设CPU1秒内吞吐量是100次。则串行方式1秒内CPU可处理的请求量是7次（1000/150）。并行方式处理的请求量是10次（1000/100）。x0dx0a小结：如以上案例描述，传统的方式系统的性能（并发量，吞吐量，响应时间）会有瓶颈。如何解决这个问题呢？x0dx0a引入消息队列，将不是必须的业务逻辑，异步处理。改造后的架构如下：x0dx0a按照以上约定，用户的响应时间相当于是注册信息写入数据库的时间，也就是50毫秒。注册邮件，发送短信写入消息队列后，直接返回，因此写入消息队列的速度很快，基本可以忽略，因此用户的响应时间可能是50毫秒。因此架构改变后，系统的吞吐量提高到每秒20 QPS。比串行提高了3倍，比并行提高了两倍。x0dx0a2.2应用解耦x0dx0a场景说明：用户下单后，订单系统需要通知库存系统。传统的做法是，订单系统调用库存系统的接口。如下图：x0dx0a传统模式的缺点：x0dx0a1） 假如库存系统无法访问，则订单减库存将失败，从而导致订单失败；x0dx0a2） 订单系统与库存系统耦合；x0dx0a如何解决以上问题呢？引入应用消息队列后的方案，如下图：x0dx0a订单系统：用户下单后，订单系统完成持久化处理，将消息写入消息队列，返回用户订单下单成功。x0dx0a库存系统：订阅下单的消息，采用拉/推的方式，获取下单信息，库存系统根据下单信息，进行库存操作。x0dx0a假如：在下单时库存系统不能正常使用。也不影响正常下单，因为下单后，订单系统写入消息队列就不再关心其他的后续操作了。实现订单系统与库存系统的应用解耦。x0dx0a2.3流量削锋x0dx0a流量削锋也是消息队列中的常用场景，一般在秒杀或团抢活动中使用广泛。x0dx0a应用场景：秒杀活动，一般会因为流量过大，导致流量暴增，应用挂掉。为解决这个问题，一般需要在应用前端加入消息队列。x0dx0a可以控制活动的人数；x0dx0a可以缓解短时间内高流量压垮应用；x0dx0a用户的请求，服务器接收后，首先写入消息队列。假如消息队列长度超过最大数量，则直接抛弃用户请求或跳转到错误页面；x0dx0a秒杀业务根据消息队列中的请求信息，再做后续处理。x0dx0a2.4日志处理x0dx0a日志处理是指将消息队列用在日志处理中，比如Kafka的应用，解决大量日志传输的问题。架构简化如下：x0dx0a日志采集客户端，负责日志数据采集，定时写受写入Kafka队列；x0dx0aKafka消息队列，负责日志数据的接收，存储和转发；x0dx0a日志处理应用：订阅并消费kafka队列中的日志数据；x0dx0a以下是新浪kafka日志处理应用案例：x0dx0a(1)Kafka：接收用户日志的消息队列。x0dx0a(2)Logstash：做日志解析，统一成JSON输出给Elasticsearch。x0dx0a(3)Elasticsearch：实时日志分析服务的核心技术，一个schemaless，实时的数据存储服务，通过index组织数据，兼具强大的搜索和统计功能。x0dx0a(4)Kibana：基于Elasticsearch的数据可视化组件，超强的数据可视化能力是众多公司选择ELK stack的重要原因。x0dx0a2.5消息通讯x0dx0a消息通讯是指，消息队列一般都内置了高效的通信机制，因此也可以用在纯的消息通讯。比如实现点对点消息队列，或者聊天室等。x0dx0a点对点通讯：x0dx0a客户端A和客户端B使用同一队列，进行消息通讯。x0dx0a聊天室通讯：x0dx0a客户端A，客户端B，客户端N订阅同一主题，进行消息发布和接收。实现类似聊天室效果。x0dx0a以上实际是消息队列的两种消息模式，点对点或发布订阅模式。模型为示意图，供参考。x0dx0a三、消息中间件示例x0dx0a3.1电商系统x0dx0a消息队列采用高可用，可持久化的消息中间件。比如Active MQ，Rabbit MQ，Rocket Mq。（1）应用将主干逻辑处理完成后，写入消息队列。消息发送是否成功可以开启消息的确认模式。（消息队列返回消息接收成功状态后，应用再返回，这样保障消息的完整性）x0dx0a（2）扩展流程（发短信，配送处理）订阅队列消息。采用推或拉的方式获取消息并处理。x0dx0a（3）消息将应用解耦的同时，带来了数据一致性问题，可以采用最终一致性方式解决。比如主数据写入数据库，扩展应用根据消息队列，并结合数据库方式实现基于消息队列的后续处理。x0dx0a3.2日志收集系统x0dx0a分为Zookeeper注册中心，日志收集客户端，Kafka集群和Storm集群（OtherApp）四部分组成。x0dx0aZookeeper注册中心，提出负载均衡和地址查找服务；x0dx0a日志收集客户端，用于采集应用系统的日志，并将数据推送到kafka队列；x0dx0a四、JMS消息服务x0dx0a讲消息队列就不得不提JMS 。JMS（Java Message Service,Java消息服务）API是一个消息服务的标准/规范，允许应用程序组件基于JavaEE平台创建、发送、接收和读取消息。它使分布式通信耦合度更低，消息服务更加可靠以及异步性。x0dx0a在EJB架构中，有消息bean可以无缝的与JM消息服务集成。在J2EE架构模式中，有消息服务者模式，用于实现消息与应用直接的解耦。x0dx0a4.1消息模型x0dx0a在JMS标准中，有两种消息模型P2P（Point to Point）,Publish/Subscribe(Pub/Sub)。x0dx0a4.1.1 P2P模式x0dx0aP2P模式包含三个角色：消息队列（Queue），发送者(Sender)，接收者(Receiver)。每个消息都被发送到一个特定的队列，接收者从队列中获取消息。队列保留着消息，直到他们被消费或超时。x0dx0aP2P的特点x0dx0a每个消息只有一个消费者（Consumer）(即一旦被消费，消息就不再在消息队列中)x0dx0a发送者和接收者之间在时间上没有依赖性，也就是说当发送者发送了消息之后，不管接收者有没有正在运行，它不会影响到消息被发送到队列x0dx0a接收者在成功接收消息之后需向队列应答成功x0dx0a如果希望发送的每个消息都会被成功处理的话，那么需要P2P模式。（架构KKQ：466097527，欢迎加入）x0dx0a4.1.2 Pub/sub模式x0dx0a包含三个角色主题（Topic），发布者（Publisher），订阅者（Subscriber） 。多个发布者将消息发送到Topic,系统将这些消息传递给多个订阅者。x0dx0aPub/Sub的特点x0dx0a每个消息可以有多个消费者x0dx0a发布者和订阅者之间有时间上的依赖性。针对某个主题（Topic）的订阅者，它必须创建一个订阅者之后，才能消费发布者的消息。x0dx0a为了消费消息，订阅者必须保持运行的状态。x0dx0a为了缓和这样严格的时间相关性，JMS允许订阅者创建一个可持久化的订阅。这样，即使订阅者没有被激活（运行），它也能接收到发布者的消息。x0dx0a如果希望发送的消息可以不被做任何处理、或者只被一个消息者处理、或者可以被多个消费者处理的话，那么可以采用Pub/Sub模型。x0dx0a4.2消息消费x0dx0a在JMS中，消息的产生和消费都是异步的。对于消费来说，JMS的消息者可以通过两种方式来消费消息。x0dx0a（1）同步x0dx0a订阅者或接收者通过receive方法来接收消息，receive方法在接收到消息之前（或超时之前）将一直阻塞；x0dx0a（2）异步x0dx0a订阅者或接收者可以注册为一个消息监听器。当消息到达之后，系统自动调用监听器的onMessage方法。x0dx0aJNDI：Java命名和目录接口,是一种标准的Java命名系统接口。可以在网络上查找和访问服务。通过指定一个资源名称，该名称对应于数据库或命名服务中的一个记录，同时返回资源连接建立所必须的信息。x0dx0aJNDI在JMS中起到查找和访问发送目标或消息来源的作用。（架构KKQ：466097527，欢迎加入）x0dx0a4.3JMS编程模型x0dx0a(1) ConnectionFactoryx0dx0a创建Connection对象的工厂，针对两种不同的jms消息模型，分别有QueueConnectionFactory和TopicConnectionFactory两种。可以通过JNDI来查找ConnectionFactory对象。x0dx0a(2) Destinationx0dx0aDestination的意思是消息生产者的消息发送目标或者说消息消费者的消息来源。对于消息生产者来说，它的Destination是某个队列（Queue）或某个主题（Topic）;对于消息消费者来说，它的Destination也是某个队列或主题（即消息来源）。x0dx0a所以，Destination实际上就是两种类型的对象：Queue、Topic可以通过JNDI来查找Destination。x0dx0a(3) Connectionx0dx0aConnection表示在客户端和JMS系统之间建立的链接（对TCP/IP socket的包装）。Connection可以产生一个或多个Session。跟ConnectionFactory一样，Connection也有两种类型：QueueConnection和TopicConnection。x0dx0a(4) Sessionx0dx0aSession是操作消息的接口。可以通过session创建生产者、消费者、消息等。Session提供了事务的功能。当需要使用session发送/接收多个消息时，可以将这些发送/接收动作放到一个事务中。同样，也分QueueSession和TopicSession。x0dx0a(5) 消息的生产者x0dx0a消息生产者由Session创建，并用于将消息发送到Destination。同样，消息生产者分两种类型：QueueSender和TopicPublisher。可以调用消息生产者的方法（send或publish方法）发送消息。x0dx0a(6) 消息消费者x0dx0a消息消费者由Session创建，用于接收被发送到Destination的消息。两种类型：QueueReceiver和TopicSubscriber。可分别通过session的createReceiver(Queue)或createSubscriber(Topic)来创建。当然，也可以session的creatDurableSubscriber方法来创建持久化的订阅者。x0dx0a(7) MessageListenerx0dx0a消息监听器。如果注册了消息监听器，一旦消息到达，将自动调用监听器的onMessage方法。EJB中的MDB（Message-Driven Bean）就是一种MessageListener。x0dx0a深入学习JMS对掌握JAVA架构，EJB架构有很好的帮助，消息中间件也是大型分布式系统必须的组件。本次分享主要做全局性介绍，具体的深入需要大家学习，实践，总结，领会。x0dx0a五、常用消息队列x0dx0a一般商用的容器，比如WebLogic，JBoss，都支持JMS标准，开发上很方便。但免费的比如Tomcat，Jetty等则需要使用第三方的消息中间件。本部分内容介绍常用的消息中间件（Active MQ,Rabbit MQ，Zero MQ,Kafka）以及他们的特点。x0dx0a5.1 ActiveMQx0dx0aActiveMQ 是Apache出品，最流行的，能力强劲的开源消息总线。ActiveMQ 是一个完全支持JMS1.1和J2EE 1.4规范的 JMS Provider实现，尽管JMS规范出台已经是很久的事情了，但是JMS在当今的J2EE应用中间仍然扮演着特殊的地位。x0dx0aActiveMQ特性如下：x0dx0a⒈ 多种语言和协议编写客户端。语言: Java,C,C++,C#,Ruby,Perl,Python,PHP。应用协议： OpenWire,Stomp REST,WS Notification,XMPP,AMQPx0dx0a⒉ 完全支持JMS1.1和J2EE 1.4规范 （持久化，XA消息，事务)x0dx0a⒊ 对spring的支持，ActiveMQ可以很容易内嵌到使用Spring的系统里面去，而且也支持Spring2.0的特性x0dx0a⒋ 通过了常见J2EE服务器（如 Geronimo,JBoss 4,GlassFish,WebLogic)的测试，其中通过JCA 1.5 resource adaptors的配置，可以让ActiveMQ可以自动的部署到任何兼容J2EE 1.4 商业服务器上x0dx0a⒌ 支持多种传送协议：in-VM,TCP,SSL,NIO,UDP,JGroups,JXTAx0dx0a⒍ 支持通过JDBC和journal提供高速的消息持久化x0dx0a⒎ 从设计上保证了高性能的集群，客户端-服务器，点对点x0dx0a⒏ 支持Ajaxx0dx0a⒐ 支持与Axis的整合x0dx0a⒑ 可以很容易得调用内嵌JMS provider，进行测试x0dx0a5.2 RabbitMQx0dx0aRabbitMQ是流行的开源消息队列系统，用erlang语言开发。RabbitMQ是AMQP（高级消息队列协议）的标准实现。支持多种客户端，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持AJAX，持久化。用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。x0dx0a几个重要概念：x0dx0aBroker：简单来说就是消息队列服务器实体。x0dx0aExchange：消息交换机，它指定消息按什么规则，路由到哪个队列。x0dx0aQueue：消息队列载体，每个消息都会被投入到一个或多个队列。x0dx0aBinding：绑定，它的作用就是把exchange和queue按照路由规则绑定起来。x0dx0aRouting Key：路由关键字，exchange根据这个关键字进行消息投递。x0dx0avhost：虚拟主机，一个broker里可以开设多个vhost，用作不同用户的权限分离。x0dx0aprocer：消息生产者，就是投递消息的程序。x0dx0aconsumer：消息消费者，就是接受消息的程序。x0dx0achannel：消息通道，在客户端的每个连接里，可建立多个channel，每个channel代表一个会话任务。x0dx0a消息队列的使用过程，如下：x0dx0a（1）客户端连接到消息队列服务器，打开一个channel。x0dx0a（2）客户端声明一个exchange，并设置相关属性。x0dx0a（3）客户端声明一个queue，并设置相关属性。x0dx0a（4）客户端使用routing key，在exchange和queue之间建立好绑定关系。x0dx0a（5）客户端投递消息到exchange。x0dx0aexchange接收到消息后，就根据消息的key和已经设置的binding，进行消息路由，将消息投递到一个或多个队列里。x0dx0a5.3 ZeroMQx0dx0a号称史上最快的消息队列，它实际类似于Socket的一系列接口，他跟Socket的区别是：普通的socket是端到端的（1:1的关系），而ZMQ却是可以N：M 的关系，人们对BSD套接字的了解较多的是点对点的连接，点对点连接需要显式地建立连接、销毁连接、选择协议（TCP/UDP）和处理错误等，而ZMQ屏蔽了这些细节，让你的网络编程更为简单。ZMQ用于node与node间的通信，node可以是主机或者是进程。x0dx0a引用官方的说法： “ZMQ(以下ZeroMQ简称ZMQ)是一个简单好用的传输层，像框架一样的一个socket library，他使得Socket编程更加简单、简洁和性能更高。是一个消息处理队列库，可在多个线程、内核和主机盒之间弹性伸缩。ZMQ的明确目标是“成为标准网络协议栈的一部分，之后进入Linux内核”。现在还未看到它们的成功。但是，它无疑是极具前景的、并且是人们更加需要的“传统”BSD套接字之上的一 层封装。ZMQ让编写高性能网络应用程序极为简单和有趣。”x0dx0a特点是：x0dx0a高性能，非持久化；x0dx0a跨平台：支持Linux、Windows、OS X等。x0dx0a多语言支持； C、C++、Java、.NET、Python等30多种开发语言。x0dx0a可单独部署或集成到应用中使用；x0dx0a可作为Socket通信库使用。x0dx0a与RabbitMQ相比，ZMQ并不像是一个传统意义上的消息队列服务器，事实上，它也根本不是一个服务器，更像一个底层的网络通讯库，在Socket API之上做了一层封装，将网络通讯、进程通讯和线程通讯抽象为统一的API接口。支持“Request-Reply “，”Publisher-Subscriber“，”Parallel Pipeline”三种基本模型和扩展模型。x0dx0aZeroMQ高性能设计要点：x0dx0a1、无锁的队列模型x0dx0a对于跨线程间的交互（用户端和session）之间的数据交换通道pipe，采用无锁的队列算法CAS；在pipe两端注册有异步事件，在读或者写消息到pipe的时，会自动触发读写事件。x0dx0a2、批量处理的算法x0dx0a对于传统的消息处理，每个消息在发送和接收的时候，都需要系统的调用，这样对于大量的消息，系统的开销比较大，zeroMQ对于批量的消息，进行了适应性的优化，可以批量的接收和发送消息。x0dx0a3、多核下的线程绑定，无须CPU切换x0dx0a区别于传统的多线程并发模式，信号量或者临界区， zeroMQ充分利用多核的优势，每个核绑定运行一个工作者线程，避免多线程之间的CPU切换开销。x0dx0a5.4 Kafkax0dx0aKafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模的网站中的所有动作流数据。 这种动作（网页浏览，搜索和其他用户的行动）是在现代网络上的许多社会功能的一个关键因素。 这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。 对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。Kafka的目的是通过Hadoop的并行加载机制来统一线上和离线的消息处理，也是为了通过集群机来提供实时的消费。x0dx0aKafka是一种高吞吐量的分布式发布订阅消息系统，有如下特性：x0dx0a通过O(1)的磁盘数据结构提供消息的持久化，这种结构对于即使数以TB的消息存储也能够保持长时间的稳定性能。（文件追加的方式写入数据，过期的数据定期删除）x0dx0a高吞吐量：即使是非常普通的硬件Kafka也可以支持每秒数百万的消息。x0dx0a支持通过Kafka服务器和消费机集群来分区消息。x0dx0a支持Hadoop并行数据加载。x0dx0aKafka相关概念x0dx0aBrokerx0dx0aKafka集群包含一个或多个服务器，这种服务器被称为broker[5]x0dx0aTopicx0dx0a每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。（物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处）x0dx0aPartitionx0dx0aParition是物理上的概念，每个Topic包含一个或多个Partition.x0dx0aProcerx0dx0a负责发布消息到Kafka brokerx0dx0aConsumerx0dx0a消息消费者，向Kafka broker读取消息的客户端。x0dx0aConsumer Groupx0dx0a每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定group name，若不指定group name则属于默认的group）。x0dx0a一般应用在大数据日志处理或对实时性（少量延迟），可靠性（少量丢数据）要求稍低的场景使用。
㈥ 在大数据中心需要什么样的技术
大数据是对坦丛海量数据进行存储、计算、统计、分析处理的一系列处理手段，处理的数据量通常是TB级，甚至是PB或EB级的数据，这是传统数据手段所无法完成的，其涉及的技术有分布式计算、高并发处理、高可用处理、集群、实时性计算等，汇集了当前IT领域热门流行的IT技术。1. Java编程技术
Java编程技术是大数据学习的基础，Java是一种强类型的语言，拥有极高的跨平台能力，可以编写桌面应用程序、Web应用程序、分布式系统和嵌入式系统应用程序等，是大数据工程师最喜欢的编程工具，因此，想学好大数据，掌握Java基础是必不可少的。
2. Linux命令
对于大数据开发通常是在Linux环境下进行的，相比Linux操作系统，Windows操作系统是封闭的操作系统，开源的大数据软件很受限制，因此，想从事大数据开发相关工作，还需掌握Linux基础操作命令。
3. Hadoop
Hadoop是大数据开发的重要框架，其核心是HDFS和MapRece，HDFS为海量的数据提供了存储，MapRece为海量的数据提供了计算，因此，需要重点掌握，除此之外，还需要掌握Hadoop集群、Hadoop集群管理、YARN以及Hadoop高级管理等相关技耐前术与操作！
4. Hive
Hive是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供简单的sql查询功能，可以将sql语句转换为MapRece任务运行，十分适合数据仓库的统计分析。对于Hive需掌握其安装、应用及高级操作等。
5. Avro与Protobuf
Avro与Protobuf均是数据序列化系统，可以提供丰富的数据结构类型，十分适合做数据存储，还可进行不同语言之间相互通信的数据交换格式，学习大数据，需掌握其具体用法。
6. ZooKeeper
ZooKeeper是Hadoop和Habase的重要组件，是一个分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组件服务等，在大数据开发中要掌握ZooKeeper的常用命令及功能的实现方法。7. HBase
HBase是一个分布式的、面向列的开源数据库，他不同于一般的关系数据库，更适合于非结构化数据存储的数据库，是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，大数据开发需掌握HBase基础知识、应用、架构以及高级用法等。
8.phoenix
Phoenix是用Java编写的基于JDBC API操作HBase的开源SQL引擎，其具有动态列、散列加载、查询服务器、追踪、事务、用户自定义函数、二级索引、命名空间映射、数据收集、行时间戳列、分页查询、跳跃查询、视图以及多租户的特性，大数据开发需掌握其原理和使用方法。
9.Redis
Redis是一个key-value存储系统，其出现很大程度补偿了memcached这类key/value存储的不足，在部分场合可以对关系数据库昌信清起到很好的补充作用，它提供了Java，C/C++，C#，PHP，JavaScript，Perl，Object-C，Python，Ruby，Erlang等客户端，使用很方便，大数据开发需掌握Redis的安装、配置及相关使用方法。
10.Flume
Flume是一款高可用、高可靠、分布式的海量日志采集、聚合和传输系统，Flume支持在日志系统中定制各类数据发送方，用于收集数据；同时，Flume提供对数据进行简单处理，并写到各种数据接收方（可定制）的能力。大数据开发需掌握其安装、配置以及相关使用方法。
11.SSM
SSM框架是由Spring、SpringMVC、MyBatis三个开源框架整合而成，常作为数据源较简单的web项目的框架。大数据开发需分别掌握Spring、SpringMVC、MyBatis三种框架的同时，再使用SSM进行整合操作。
12.Kafka
Kafka是一种高吞吐量的分布式发布订阅消息系统，其在大数据开发应用上的目的是通过Hadoop的并行加载机制来统一线上和离线的消息处理，也是为了通过集群来提供实时的消息。大数据开发需掌握Kafka架构原理及各组件的作用和是用方法及相关功能的实现！
13.Scala
Scala是一门多范式的编程语言，大数据开发重要框架Spark是采用Scala语言设计的，想要学好Spark框架，拥有Scala基础是必不可少的，因此，大数据开发需掌握Scala编程基础知识！
14.Spark
Spark是专为大规模数据处理而设计的快速通用的计算引擎，其提供了一个全面、统一的框架用于管理各种不同性质的数据集和数据源的大数据处理的需求，大数据开发需掌握Spark基础、SparkJob、Spark RDD、sparkjob部署与资源分配、SparkshuffleSpark内存管理、Spark广播变量、SparkSQL SparkStreaming以及 Spark ML等相关知识。
15.Azkaban
Azkaban是一个批量工作流任务调度器，可用于在一个工作流内以一个特定的顺序运行一组工作和流程，可以利用Azkaban来完成大数据的任务调度，大数据开发需掌握Azkaban的相关配置及语法规则。
㈦ php 高并发解决思路解决方案
php 高并发解决思路解决方案，如何应对网站大流量高并发情况。本文为大家总结了常用的处理方式，但不是细节，后续一系列细节教程给出。希望大家喜欢。
一 高并发的概念
在互联网时代，并发，高并发通常是指并发访问。也就是在某个时间点，有多少个访问同时到来。
二 高并发架构相关概念
1、QPS (每秒查询率) : 每秒钟请求或者查询的数量，在互联网领域，指每秒响应请求数(指 HTTP 请求)
2、PV（Page View）：综合浏览量，即页面浏览量或者点击量，一个访客在 24 小时内访问的页面数量
--注：同一个人浏览你的网站的同一页面，只记做一次 pv
3、吞吐量（fetches/sec） ：单位时间内处理的请求数量 （通常由 QPS 和并发数决定）
4、响应时间：从请求发出到收到响应花费的时间
5、独立访客（UV）：一定时间范围内，相同访客多次访问网站，只计算为 1 个独立访客
6、带宽：计算带宽需关注两个指标，峰值流量和页面的平均大小
7、日网站带宽： PV/统计时间（换算到秒） * 平均页面大小（kb）* 8
三 需要注意点：
1、QPS 不等于并发连接数（QPS 是每秒 HTTP 请求数量，并发连接数是系统同时处理的请求数量）
2、峰值每秒请求数（QPS）= （总 PV 数*80%）/ （六小时秒数*20%）【代表 80%的访问量都集中在 20%的时间内】
3、压力测试： 测试能承受的最大并发数 以及测试最大承受的 QPS 值
4、常用的性能测试工具【ab，wrk，httpload，Web Bench，Siege，Apache JMeter】
四 优化
1、当 QPS 小于 50 时
优化方案:为一般小型网站,不用考虑优化
2、当 QPS 达到 100 时,遇到数据查询瓶颈
优化方案: 数据库缓存层,数据库的负载均衡
3、当 QPS 达到 800 时, 遇到带宽瓶颈
优化方案:CDN 加速,负载均衡
4、当 QPS 达到 1000 时
优化方案: 做 html 静态缓存
5、当 QPS 达到 2000 时
优化方案: 做业务分离,分布式存储
五、高并发解决方案案例:
1、流量优化
防盗链处理(去除恶意请求)
2、前端优化
(1) 减少 HTTP 请求[将 css,js 等合并]
(2) 添加异步请求(先不将所有数据都展示给用户,用户触发某个事件,才会异步请求数据)
(3) 启用浏览器缓存和文件压缩
(4) CDN 加速
(5) 建立独立的图片服务器(减少 I/O)
3、服务端优化
(1) 页面静态化
(2) 并发处理
(3) 队列处理
4、数据库优化
(1) 数据库缓存
(2) 分库分表,分区
(3) 读写分离
(4) 负载均衡
5、web 服务器优化
(1) nginx 反向代理实现负载均衡
(2) lvs 实现负载均衡