php授权机制

㈠ MVC怎么设置权限

MVC模式是"Model-View-Controller"的缩写，中文翻译为"模式-视图-控制器"。MVC应用程序总是由这三个部分组成。Event(事件)导致Controller改变Model或View，或者同时改变两者。只要Controller改变了Models的数据或者属性，所有依赖的View都会自动更新。类似的，只要Controller改变了View，View会从潜在的Model中获取数据来刷新自己。MVC模式最早是smalltalk语言研究团提出的，应用于用户交互应用程序中。smalltalk语言和java语言有很多相似性,都是面向对象语言，很自然的SUN在petstore(宠物店)事例应用程序中就推荐MVC模式作为开发Web应用的架构模式。MVC模式是一种架构模式，其实需要其他模式协作完成。在J2EE模式目录中，通常采用service to worker模式实现，而service to worker模式可由集中控制器模式，派遣器模式和Page Helper模式组成。而Struts只实现了MVC的View和Controller两个部分，Model部分需要开发者自己来实现，Struts提供了抽象类Action使开发者能将Model应用于Struts框架中。

MVC模式是一个复杂的架构模式，其实现也显得非常复杂。但是，我们已经终结出了很多可靠的设计模式，多种设计模式结合在一起，使MVC模式的实现变得相对简单易行。Views可以看作一棵树，显然可以用Composite Pattern来实现。Views和Models之间的关系可以用Observer Pattern体现。Controller控制Views的显示，可以用Strategy Pattern实现。Model通常是一个调停者，可采用Mediator Pattern来实现。

现在让我们来了解一下MVC三个部分在J2EE架构中处于什么位置，这样有助于我们理解MVC模式的实现。MVC与J2EE架构的对应关系是:View处于Web Tier或者说是Client Tier，通常是JSP/Servlet，即页面显示部分。Controller也处于Web Tier，通常用Servlet来实现，即页面显示的逻辑部分实现。Model处于Middle Tier，通常用服务端的javaBean或者EJB实现，即业务逻辑部分的实现。

一、MVC设计思想

MVC英文即Model-View-Controller，即把一个应用的输入、处理、输出流程按照Model、View、Controller的方式进行分离，这样一个应用被分成三个层——模型层、视图层、控制层。

视图(View)代表用户交互界面，对于Web应用来说，可以概括为HTML界面，但有可能为XHTML、XML和Applet。随着应用的复杂性和规模性，界面的处理也变得具有挑战性。一个应用可能有很多不同的视图，MVC设计模式对于视图的处理仅限于视图上数据的采集和处理，以及用户的请求，而不包括在视图上的业务流程的处理。业务流程的处理交予模型(Model)处理。比如一个订单的视图只接受来自模型的数据并显示给用户，以及将用户界面的输入数据和请求传递给控制和模型。

模型(Model)：就是业务流程/状态的处理以及业务规则的制定。业务流程的处理过程对其它层来说是黑箱操作，模型接受视图请求的数据，并返回最终的处理结果。业务模型的设计可以说是MVC最主要的核心。目前流行的EJB模型就是一个典型的应用例子，它从应用技术实现的角度对模型做了进一步的划分，以便充分利用现有的组件，但它不能作为应用设计模型的框架。它仅仅告诉你按这种模型设计就可以利用某些技术组件，从而减少了技术上的困难。对一个开发者来说，就可以专注于业务模型的设计。MVC设计模式告诉我们，把应用的模型按一定的规则抽取出来，抽取的层次很重要，这也是判断开发人员是否优秀的设计依据。抽象与具体不能隔得太远，也不能太近。MVC并没有提供模型的设计方法，而只告诉你应该组织管理这些模型，以便于模型的重构和提高重用性。我们可以用对象编程来做比喻，MVC定义了一个顶级类，告诉它的子类你只能做这些，但没法限制你能做这些。这点对编程的开发人员非常重要。

业务模型还有一个很重要的模型那就是数据模型。数据模型主要指实体对象的数据 保存（持续化）。比如将一张订单保存到数据库，从数据库获取订单。我们可以将这个模型单独列出，所有有关数据库的操作只限制在该模型中。

控制(Controller)可以理解为从用户接收请求, 将模型与视图匹配在一起，共同完成用户的请求。划分控制层的作用也很明显，它清楚地告诉你，它就是一个分发器，选择什么样的模型，选择什么样的视图，可以完成什么样的用户请求。控制层并不做任何的数据处理。例如，用户点击一个连接，控制层接受请求后, 并不处理业务信息，它只把用户的信息传递给模型，告诉模型做什么，选择符合要求的视图返回给用户。因此，一个模型可能对应多个视图，一个视图可能对应多个模型。

模型、视图与控制器的分离，使得一个模型可以具有多个显示视图。如果用户通过某个视图的控制器改变了模型的数据，所有其它依赖于这些数据的视图都应反映到这些变化。因此，无论何时发生了何种数据变化，控制器都会将变化通知所有的视图，导致显示的更新。这实际上是一种模型的变化-传播机制。模型、视图、控制器三者之间的关系和各自的主要功能，如图1所示。

二、MVC设计模式的实现

ASP.NET提供了一个很好的实现这种经典设计模式的类似环境。开发者通过在ASPX页面中开发用户接口来实现视图；控制器的功能在逻辑功能代码(.cs)中实现；模型通常对应应用系统的业务部分。在ASP.NET中实现这种设计而提供的一个多层系统，较经典的ASP结构实现的系统来说有明显的优点。将用户显示（视图）从动作（控制器）中分离出来,提高了代码的重用性。将数据（模型）从对其操作的动作（控制器）分离出来可以让你设计一个与后台存储数据无关的系统。就MVC结构的本质而言，它是一种解决耦合系统问题的方法。

2.1 视图

视图是模型的表示，它提供用户交互界面。使用多个包含单显示页面的用户部件，复杂的Web页面可以展示来自多个数据源的内容，并且网页人员，美工能独自参与这些Web页面的开发和维护。

在ASP.NET下，视图的实现很简单。可以像开发WINDOWS界面一样直接在集成开发环境下通过拖动控件来完成页面开发本。本文中介绍每一个页面都采用复合视图的形式即：一个页面由多个子视图(用户部件)组成；子视图可以是最简单HTML 控件、服务器控件或多个控件嵌套构而成的Web自定义控件。页面都由模板定义，模板定义了页面的布局，用户部件的标签和数目，用户指定一个模板，平台根据这些信息自动创建页面。针对静态的模板内容，如页面上的站点导航，菜单，友好链接，这些使用缺省的模板内容配置；针对动态的模板内容(主要是业务内容)，由于用户的请求不同，只能使用后期绑定，并且针对用户的不同，用户部件的显示内容进行过滤。使用由用户部件根据模板配置组成的组合页面，它增强了可重用性，并原型化了站点的布局。

视图部分大致处理流程如下：首先，页面模板定义了页面的布局；页面配置文件定义视图标签的具体内容（用户部件）；然后，由页面布局策略类初始化并加载页面；每个用户部件根据它自己的配置进行初始化，加载校验器并设置参数，以及事件的委托等；用户提交后，通过了表示层的校验，用户部件把数据自动提交给业务实体即模型。

这一部分主要定义了WEB页面基类PageBase；页面布局策略类PageLayout，完成页面布局，用于加载用户部件到页面；用户部件基类UserControlBase即用户部件框架，用于动态加载检验部件，以及实现用户部件的个性化。为了实现WEB应用的灵活性，视图部分也用到了许多配置文件例如：置文件有模板配置、页面配置、路径配置、验证配置等。

2.2 控制器

为了能够控制和协调每个用户跨越多个请求的处理，控制机制应该以集中的方式进行管理。因此，为了达到集中管理的目的引入了控制器。应用程序的控制器集中从客户端接收请求（典型情况下是一个运行浏览器的用户），决定执行什么商业逻辑功能，然后将产生下一步用户界面的责任委派给一个适当的视图组件。

用控制器提供一个控制和处理请求的集中入口点，它负责接收、截取并处理用户请求；并将请求委托给分发者类，根据当前状态和业务操作的结果决定向客户呈现的视图。在这一部分主要定义了HttpReqDispatcher(分发者类)、HttpCapture(请求捕获者类)、Controller(控制器类)等，它们相互配合来完成控制器的功能。请求捕获者类捕获HTTP请求并转发给控制器类。控制器类是系统中处理所有请求的最初入口点。控制器完成一些必要的处理后把请求委托给分发者类；分发者类分发者负责视图的管理和导航，它管理将选择哪个视图提供给用户，并提供给分发资源控制。在这一部分分别采用了分发者、策略、工厂方法、适配器等设计模式。

为了使请求捕获者类自动捕获用户请求并进行处理，ASP.NET 提供低级别的请求/响应 API，使开发人员能够使用 .NET 框架类为传入的 HTTP 请求提供服务。为此，必须创作支持 System.Web.IHTTPHandler 接口和实现 ProcessRequest() 方法的类即：请求捕获者类，并在web.config 的 ＜httphandlers＞ 节中添加类。ASP.NET 收到的每个传入 HTTP 请求最终由实现 IHTTPHandler 的类的特定实例来处理。IHttpHandlerFactory 提供了处理 IHttpHandler 实例 URL 请求的实际解析的结构。HTTP 处理程序和工厂在 ASP.NET 配置中声明为 web.config 文件的一部分。ASP.NET 定义了一个 ＜httphandlers＞ 配置节，在其中可以添加和移除处理程序和工厂。子目录继承 HttpHandlerFactory 和 HttpHandler 的设置。 HTTP 处理程序和工厂是 ASP.NET 页框架的主体。工厂将每个请求分配给一个处理程序，后者处理该请求。 例如，在全局 machine.config 文件中，ASP.NET 将所有对 ASPx 文件的请求映射到 HttpCapture类：

＜httphandlers＞
...
...
＜/httphandlers＞

2.3 模型

MVC系统中的模型从概念上可以分为两类――系统的内部状态和改变系统状态的动作。模型是你所有的商业逻辑代码片段所在。本文为模型提供了业务实体对象和业务处理对象：所有的业务处理对象都是从ProcessBase类派生的子类。业务处理对象封装了具体的处理逻辑，调用业务逻辑模型，并且把响应提交到合适的视图组件以产生响应。业务实体对象可以通过定义属性描述客户端表单数据。所有业务实体对象都EntityBase派生子类对象，业务处理对象可以直接对它进行读写，而不再需要和request、response对象进行数据交互。通过业务实体对象实现了对视图和模型之间交互的支持。实现时把"做什么"（业务处理）和"如何做"（业务实体）分离。这样可以实现业务逻辑的重用。由于各个应用的具体业务是不同的，这里不再列举其具体代码实例。

三、MVC设计模式的扩展

通过在ASP.NET中的MVC模式编写的，具有极其良好的可扩展性。它可以轻松实现以下功能：

①实现一个模型的多个视图；

②采用多个控制器；

③当模型改变时，所有视图将自动刷新；

④所有的控制器将相互独立工作。

这就是MVC模式的好处，只需在以前的程序上稍作修改或增加新的类，即可轻松增加许多程序功能。以前开发的许多类可以重用，而程序结构根本不再需要改变，各类之间相互独立，便于团体开发，提高开发效率。下面讨论如何实现一个模型、两个视图和一个控制器的程序。其中模型类及视图类根本不需要改变，与前面的完全一样，这就是面向对象编程的好处。对于控制器中的类，只需要增加另一个视图，并与模型发生关联即可。该模式下视图、控制器、模型三者之间的示意图如图2所示。

同样也可以实现其它形式的MVC例如：一个模型、两个视图和两个控制器。从上面可以看出，通过MVC模式实现的应用程序具有极其良好的可扩展性，是ASP.NET面向对象编程的未来方向。

四、MVC的优点

大部分用过程语言比如ASP、php开发出来的Web应用，初始的开发模板就是混合层的数据编程。例如，直接向数据库发送请求并用HTML显示,开发速度往往比较快,但由于数据页面的分离不是很直接,因而很难体现出业务模型的样子或者模型的重用性。产品设计弹性力度很小，很难满足用户的变化性需求。MVC要求对应用分层，虽然要花费额外的工作，但产品的结构清晰，产品的应用通过模型可以得到更好地体现。

首先，最重要的是应该有多个视图对应一个模型的能力。在目前用户需求的快速变化下，可能有多种方式访问应用的要求。例如，订单模型可能有本系统的订单，也有网上订单，或者其他系统的订单，但对于订单的处理都是一样，也就是说订单的处理是一致的。按MVC设计模式，一个订单模型以及多个视图即可解决问题。这样减少了代码的复制，即减少了代码的维护量，一旦模型发生改变，也易于维护。 其次，由于模型返回的数据不带任何显示格式，因而这些模型也可直接应用于接口的使用。

再次，由于一个应用被分离为三层，因此有时改变其中的一层就能满足应用的改变。一个应用的业务流程或者业务规则的改变只需改动MVC的模型层。

控制层的概念也很有效，由于它把不同的模型和不同的视图组合在一起完成不同的请求，因此，控制层可以说是包含了用户请求权限的概念。

最后，它还有利于软件工程化管理。由于不同的层各司其职，每一层不同的应用具有某些相同的特征，有利于通过工程化、工具化产生管理程序代码。

五、MVC的不足

MVC的不足体现在以下几个方面：

（1）增加了系统结构和实现的复杂性。对于简单的界面，严格遵循MVC，使模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。

（2）视图与控制器间的过于紧密的连接。视图与控制器是相互分离，但确实联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。

（3）视图对模型数据的低效率访问。依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。

（4） 目前，一般高级的界面工具或构造器不支持MVC模式。改造这些工具以适应MVC需要和建立分离的部件的代价是很高的，从而造成使用MVC的困难。

㈡ 手机微信内置的浏览器缓存怎样用php清除

逻辑理清：
1.
1.1如果用户扫描带参数的公众号二维码（这个微信提供有接口），未关注的用户扫描之后如果则直接跳转到公众号详情页，详情页会有一个关注按钮，关注过的用户扫描之后会进入到公众号的会话界面；
1.2如果用户关注公众号，会向你的开发者url推送一个关注消息（取关也会推送一个消息），你可以以此标记用户的状态（是关注，还是取关，或者只是网页授权了一下），有了上面这个状态，当一个微信用户进入你开发的网页（网页是运行在微信内置浏览器里）你可以通过静默授权的方式获取用户在数据库中的状态（即关注/取关/网页授权）。
2.当然在开发者的网页里面是不能直接跳转到公众号的详情页的。
3.关注后也是不能跳转url的

微信网页授权

如果用户在微信客户端中访问第三方网页，公众号可以通过微信网页授权机制，来获取用户基本信息，进而实现业务逻辑。

网页链接

㈢ 小米4主题能破解吗

能。方法如下：

一、安装前的准备

1. ROOT手机

2. 网络一下分别下载WSM工具箱_WSM_tools和Mi-Tools两个软件到电脑，然后将它们传送到手机。

3. 特别注意：文末下载的WSM是旧版本，小米更改了验证机制，旧版本已失效。故：下载好旧版后，一定要在手机上先更新！

4. 这两个软件都是apk格式的手机软件，也就是说：这种方式是在手机上破解主题的，而之前的方法是在电脑上破解的。这是两种方法的区别所在。

5. 下载好后分别安装他们，注意：此时不要运行这两个程序，安装好就行了！切记！

二、首先运行WSM工具箱

1. 首先普及什么是WSM工具箱

   WSM工具箱就是MIUI上的Xposed框架，基于它可以制作出许多功能强大的模块，且在功能不冲突的情况下同时运作。对于此教程，使用WSM工具箱，就是为了集成另外那个程序Mi-Tools这个模块的！

2. 运行WSM工具箱，出现如下界面，然后单击安装。

   注意：两个软件一定要首先运行WSM工具箱

3. 出现提示：DONE(安装完成)，请REBOOT（重启）

   单击：确定，即可重启手机。

三、查看MI-TOOL模块是否集成在WSM工具箱

重启手机后，运行MI-TOOL，查看MI-TOOL主界面，MI-TOOL模块已经集成在WSM工具箱。

四、再次运行WSM工具箱

此举是为了打开WSM工具箱里集成好的MI-TOOLS模块。

注意：此举是成败关键，默认是关闭的，只有打开了，才能破解主题。

重启手机，重启后，再把电脑上下载好的主题传到手机上，就可以破解验证了！再也不会说：该主题不是从官方市场下载！

五、到电脑上破解下载主题

1. 把下载好的主题拷贝手机根目录或SD卡中

2. 打开“小米主题”软件，然后选择“我的主题”

3. 按功能键，选择从SD导入主题包就行了！
   

㈣ 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系统变大的过程，实际上就是我们解决问题的过程。在不同的阶段，解决不同的问题，而新的问题又诞生在旧的解决方案之上。

系统的优化是没有极限的，软件和系统架构也一直在快速发展，新的方案解决了老的问题，同时也带来新的挑战。

㈤ 新买的小米为什么主题换不了

客服说是系统的问题 会在下次升级的时候优化 如果更换主题确实没用 请选择设置-系统-关于手机-恢复出厂设置-清空所有数据，重启后就好了，我刚刚问了客服回来，清了之后我的主题和字体都可以配置了。

㈥ 金和通的金和通的优势

1、更方便
①只需安装一次
从网站下载金和通安装包或获得金和通安装光盘后，在服务器端安装一次，做好相应部署，贵企业所有用户就可以在企业网络环境（局域网或广域网）中使用金和通。
②完全基于Web
依靠金和通，用户即可通过桌面浏览器和WAP浏览器与身边的同事，异地的客户，跨国供应商等实现愉快的沟通。
③无需培训即可使用
在用户体验上，金和通取个人常用即时通信工具与邮件系统之长。清晰的帮助条目和在线的帮助渠道能让用户在使用过程中倍感轻松。2、更高效
①组织结构完全展现
对于有一定规模的企业，金和通可以醒目且详细的显示组织结构，辅以关联下级，多条件查询等功能，从而使您能够快捷地找到沟通对象。
②发送明细及时提醒
当发送相对复杂的寻呼(发送人多，附件多)，在发送之前，可以先仔细检查一下发送状态，从而有效避免错误，疏漏，重复现象。
③与其他业务系统无缝集成
金和通有开放的访问接口与二次开发接口，可与企业其他业务系统(OA、CRM、ERP等)实现实时协同。
3、更精确
①主送、抄送、密送功能
当发送寻呼时，可设置相应的接受人类别，使责任更明确，精确的寻呼发送方式和接受情况有效避免了扯皮和责任推诿现象。
②寻呼的串联
具有相关性的寻呼可以自动串联在一起，沟通的来龙去脉一目了然。此外，寻呼列表中，附件、时间、内容等精确陈列，呈现更趋合理。 更大、更全面的展示视图，清晰地展现企业内部多层次组织架构，便于每个员工迅速融入企业中。即使在彼此不认识的情况下，根据部门属性找到相关人员进行沟通协作，可极大提高内部沟通效率。如组织机构变换，只需在服务器端快捷的做配置。
①支持一人多职，更符合中国企业组织实际情况,解决了多数同类软件不能有效解决兼职的问题。
②支持虚拟组织，企业还可将生意伙伴(供应商和客户)加入组织机构形成虚拟组织机构，让企业的沟通范围更加广泛，并且丝毫不增加生意伙伴的负担。
5、得心应手的实现个人设定根据实际工作的需要，你可以按项目、业务、职务等自建多个团组以加速你的沟通协作。用户可预设不同时间段的状态（如离开，会议等，可随意编辑）。这样，别人与你进行沟通前就可准确获知你的状态，并根据你的状态决定与你沟通的最佳时机。改良了多数沟通工具需要主动设置“消息回执”的功能，系统中每个寻呼都有详细的寻呼回执，可看到对方是否已接受以及精确的接收时间。
6、零成本拥有
信息化成本=软件+硬件+培训+维护等。金和通完全免费（200用户内），其使用的MySQL数据库和Apache Web服务器也是完全免费且性能稳定高效，并无需额外硬件投入。
使用简单便捷，无须培训，全员即可轻松上手。
■ 支持WAP访问方式，随时随地进行沟通安装包内置WAP应用，支持手机上网的用户收发寻呼更方便。
■ 独享金和产品用户专属的金和社区服务金和社区服务平台是面向金和客户开放的增值服务系统，是金和产品应用的有效延伸。该平台面向广大客户的白领阶层，将协同管理软件产品与服务提供方式便捷、有机的整合在一起，客户通过点击产品中的“在线服务”，即可访问金和社区。
社区除了提供标准支持服务外，还增设了自助服务、案例技巧分享、成果展示、白领个性化空间、服务提醒、互动课堂、金融资讯、健康养生等一系列增值服务功能，面向客户完全开放权限，不设置“门槛”。让广大的金和产品用户（个人/企业）在享受金和“精确服务”的同时，获得更多便捷和超乎想象的收益和体验。
■ 您值得信赖的技术架构体系金和通基于成熟稳定、性价比高的AMP(Apach+MySQL+PHP)技术开发，采用三层架构体系，应用MVC设计模式，运用了大量先进的诸如Ajax、Ext等web2.0的技术，增强了系统的柔性和开放性，是一套高度封装、简单易用、方便推广的企业即时沟通平台。平台体系架构采用三层架构体系，分别是表示层、中间层、数据层，实现了“高内聚，低耦合”的设计思想。 金和，中国协同信息化领域第一品牌。十余年来，一直致力于将精确管理理论融入中国企业管理，金和的C6,IOA等协同软件产品线已经累积了上万家企业用户。
经过这些用户的实践，金和发现，在使用过程中，有一个模块拥有100%的使用率。这就是金和协同软件产品的核心模块-网络寻呼，这说明在各种企业内部，都有稳定的即时交流需求，这也是企业日常工作和运营的关键需求。
经过深思熟虑之后，金和决定以网络寻呼模块，结合精确管理理论与中国企业实际需求，开发出一款能让中国企业都能永久免费使用的即时通信软件，降低企业沟通成本，实现企业高效精确沟通，从而给企业实现协同管理奠定基础。
让更多的企业享受精确管理，这就是金和作为公众公司的义务。全心全意为人民服务，是金和不断推陈出新，完善产品的最终目标。 ■ 组织结构及人员管理系统提供最多五级组织结构，支持部门显示顺序的调整。
■ 系统支持用户兼职、面向用户进行授权、用户权限查看、密码有效期设置等。
■ 组织结构及人员导入导出系统支持Excel格式部门和人员的数据文件的导入导出，并提供导入模板下载。通过方便的导入导出，让你高效快速部署金和通。
■ 发送内部通知授权用户可通过全选人员发送网络寻呼，相当于一个方便的公司内部通知。
■ 服务器管理：启动、停止、重启、软件升级管理员可方便地管理金和通相关服务：启动、停止、重启；软件升级方式同样采用一键式安装升级包。
■ 权限管理金和通权限管理采用标准的按角色授权机制并支持对权限范围进行控制，可对角色绑定多个用户也可对用户绑定多个角色。
■ 系统设置通过系统设置，可以集中配置系统可使用的邮箱服务器，使系统内部用户只能使用系统配置的邮箱服务，配置更方便，发送接收邮件更安全。 ■ 发送寻呼
① 离线发送寻呼：发送寻呼不用关心对方是否在线，在线用户将立即收到寻呼，离线用户登录上线后也将获取到寻呼提醒通知。
②消息回执 抛弃了传统沟通工具需要主动设置“消息回执”的功能，系统中每个寻呼都有详细的寻呼回执，可看到对方是否已接受以及准确的接收时间。
③ 按织结构方式寻呼：系统默认提供按组织结构方式发送寻呼，组织结构方式为金和独创的大视图组织结构展现方式。
④ 按团组发送寻呼：你根据工作和项目的需要可以创建自己的多个团组，通过团组方式发送寻呼更方便、更快捷。
⑤ 寻呼优先级：系统将寻呼分为普通寻呼和紧急寻呼，在发送前可以设置，紧急寻呼位于用户的未阅寻呼列表的靠前位置，同时紧急寻呼有“！”标示。
⑥ 快速发送：通过使用自定义短语和寻呼快捷发送键“Ctrl+Enter”让你发送寻呼更方便快捷。
⑦集中统一消息发送入口：用户通过集中入口可同时亦可单独发送内部网络寻呼、邮件。
■ 多方式未阅寻呼提醒
用户收到新寻呼后，系统将在右下脚以弹出窗口方式提醒用户，同时有声音提醒。
如果你不在机器旁回来后系统将通过导航菜单的未阅寻呼菜单项和系统右下脚的闪烁图标提示你有新的未阅寻呼及未阅条数。
■ 回复寻呼和转发寻呼用户根据需要可以对已发寻呼、已收寻呼、保留寻呼进行回复和转发。
■ 保留寻呼系统的“保留寻呼”功能相当与“寻呼收藏夹”,用户可以将重点关注的寻呼进行保留。
■ 查询寻呼用户可以方便的查询自己的已发寻呼和已收寻呼，寻呼查询条件包括寻呼起止日期、发送人、接受人、寻呼内容、附件等。
■ 管理寻呼部门领导或授权用户可以通过“管理寻呼”查看其权限范围内用户的寻呼沟通记录，包括已发寻呼和已收寻呼，并可根据需要通过回复进行指点，通过转发让更多人进行关注和了解；同时可以根据工作需要对相关寻呼进行删除。
■ 状态管理除了提供多数沟通工具提供的即时切换系统提供的状态外，金和通提供了强大的自定义状态管理功能，通过该功能，你可以预先定好不同时间段的状态（状态可以自己随意编辑），系统会定时调整你的状态为你预设的状态，同时自定义状态也可以作为自己每天的备忘录和定时器，别人与你进行沟通前可准确获知你的状态，会根据你的状态决定与你沟通的最佳时机。
■ 个人设置系统提供的个人设置可以设置个人基本信息、联系信息、个性签名，也可以上传多种格式的形象照片。
■ 团组管理在工作中，你与部分同事可能会因为项目的原因沟通的频率比较高，但你们可能来自不同的部门，在庞大的组织结构中，每次沟通前找人都是比较痛苦和低效的。通过团组管理，你可以根据项目和工作需要，将经常需要沟通的同事加入自定义团组，这样每次沟通时通过“我的团组”就可以实现快速高效沟通。
■ 企业通讯录发送寻呼中的组织结构列表同时也是一个高效的“企业通讯录”，通过该功能你可以快速定位到你要找的人，并可以快速获取目标用户的概要信息和详细信息。
■ 通讯录查询发送寻呼提供了强大的用户查询功能，你可以通过姓名、用户ID号、手机号、拼音码快速地模糊匹配查询到目标用户。 服务器端环境： 在线用户数 CPU/内核
(主频1.6GHZ) 内存 操作系统 50 1 1G Windows XP 以上 100 2 2G Windows 2000以上 150 3 2G Windows 2000以上 200 4 2G以上 Windows 2000以上 其他：
金和通安装包内置：
APACHE2，MYSQL5 ，PHP5，ZEND Optimizer-3.3.0
客户端使用环境：
1） Windows 系列操作系统,IE6,IE7。
2） 支持WAP1.2以上可上网手机

㈦ 怎样将访问URL变成REST风格

我觉得问题很好：REST -- REpresentational State Transfer 直接翻译：表现层状态转移。这个中文直译经常出现在很多博客中。尼玛谁听得懂“表现层状态转移”？这是人话吗？我自己也困惑了很久，查询了很多资料，花了差不多一年有个还算清晰的理解。分享如下：

@Ivony
老师的一句话概括很精辟：
URL定位资源，用HTTP动词（GET,POST,DELETE,DETC）描述操作。

--- 简洁版 ---

0. REST不是"rest"这个单词，而是几个单词缩写。但即使那几个单词说出来，也无法理解在说什么 -_-!! （不是要贬低人，是我自己也理解困难）；
1. REST描述的是在网络中client和server的一种交互形式；REST本身不实用，实用的是如何设计 RESTful API（REST风格的网络接口）；
2. Server提供的RESTful API中，URL中只使用名词来指定资源，原则上不使用动词。“资源”是REST架构或者说整个网络处理的核心。比如：
http://api.qc.com/v1/newsfeed: 获取某人的新鲜;
http://api.qc.com/v1/friends: 获取某人的好友列表;
http://api.qc.com/v1/profile: 获取某人的详细信息;3. 用HTTP协议里的动词来实现资源的添加，修改，删除等操作。即通过HTTP动词来实现资源的状态扭转：
GET 用来获取资源，
POST 用来新建资源（也可以用于更新资源），
PUT 用来更新资源，
DELETE 用来删除资源。比如：
DELETE http://api.qc.com/v1/friends: 删除某人的好友 （在http parameter指定好友id）
POST http://api.qc.com/v1/friends: 添加好友
UPDATE http://api.qc.com/v1/profile: 更新个人资料
禁止使用： GET http://api.qc.com/v1/deleteFriend 图例：
<img src="https://pic1.mg.com/_b.jpg" data-rawwidth="1328" data-rawheight="702" class="origin_image zh-lightbox-thumb" width="1328" data-original="https://pic1.mg.com/_r.jpg">

4. Server和Client之间传递某资源的一个表现形式，比如用JSON，XML传输文本，或者用JPG，WebP传输图片等。当然还可以压缩HTTP传输时的数据（on-wire data compression）。
5. 用 HTTP Status Code传递Server的状态信息。比如最常用的 200 表示成功，500 表示Server内部错误等。
主要信息就这么点。最后是要解放思想，Web端不再用之前典型的PHP或JSP架构，而是改为前段渲染和附带处理简单的商务逻辑（比如AngularJS或者BackBone的一些样例）。Web端和Server只使用上述定义的API来传递数据和改变数据状态。格式一般是JSON。iOS和android同理可得。由此可见，Web，iOS，Android和第三方开发者变为平等的角色通过一套API来共同消费Server提供的服务。

--- 详细版 ---
先说REST名称
REST -- REpresentational State Transfer
首先，之所以晦涩是因为前面主语被去掉了，全称是 Resource Representational State Transfer：通俗来讲就是：资源在网络中以某种表现形式进行状态转移。分解开来：
Resource：资源，即数据（前面说过网络的核心）。比如 newsfeed，friends等；
Representational：某种表现形式，比如用JSON，XML，JPEG等；
State Transfer：状态变化。通过HTTP动词实现。
REST的出处
Roy Fielding的毕业论文。这哥们参与设计HTTP协议，也是Apache Web Server项目（可惜现在已经是 nginx 的天下）的co-founder。PhD的毕业学校是 UC Irvine，Irvine在加州，有着充裕的阳光和美丽的海滩，是着名的富人区。Oculus VR 的总部就坐落于此（虚拟现实眼镜，被FB收购，CTO为Quake和Doom的作者 John Carmack）。
众说周知，论文都是晦涩难懂的。当年在CMU读书的时候，很多课程都会安排每周两篇的Paper review。现在回想起来每次写Paper review都是我最为痛苦的时候。REST这篇博士论文毫无疑问更甚。
论文地址：Architectural Styles and the Design of Network-based Software Architectures
REST章节：Fielding Dissertation: CHAPTER 5: Representational State Transfer (REST)
REST那章我初读了，整个论文没有读完 =_=
<img src="https://pic3.mg.com/_b.jpg" data-rawwidth="500" data-rawheight="375" class="origin_image zh-lightbox-thumb" width="500" data-original="https://pic3.mg.com/_r.jpg">

RESTful API
实用的是如何正确地理解 RESTful架构和设计好RESTful API。
首先为什么要用RESTful结构呢？
大家都知道"古代"网页是前端后端融在一起的，比如之前的PHP，JSP等。在之前的桌面时代问题不大，但是近年来移动互联网的发展，各种类型的Client层出不穷，RESTful可以通过一套统一的接口为 Web，iOS和Android提供服务。另外对于广大平台来说，比如Facebook platform，微博开放平台，微信公共平台等，它们不需要有显式的前端，只需要一套提供服务的接口，于是RESTful更是它们最好的选择。在RESTful架构下：
<img src="https://pic2.mg.com/_b.jpg" data-rawwidth="550" data-rawheight="250" class="origin_image zh-lightbox-thumb" width="550" data-original="https://pic2.mg.com/_r.jpg">
Server的API如何设计才满足RESTful要求?
首先是简洁版里面的那几点。外加一些附带的 best practices：
1. URL root:
https://example.org/api/v1/*
https://api.example.com/v1/*2. API versioning:
可以放在URL里面，也可以用HTTP的header：
/api/v1/
3. URI使用名词而不是动词，且推荐用复数。
BAD

/getProcts
/listOrders
/retrieveClientByOrder?orderId=1
GOOD

GET /procts : will return the list of all procts
POST /procts : will add a proct to the collection
GET /procts/4 : will retrieve proct #4
PATCH/PUT /procts/4 : will update proct #4
4. 保证 HEAD 和 GET 方法是安全的，不会对资源状态有所改变（污染）。比如严格杜绝如下情况：
GET /deleteProct?id=1
5. 资源的地址推荐用嵌套结构。比如：
GET /friends/10375923/profile
UPDATE /profile/primaryAddress/city6. 警惕返回结果的大小。如果过大，及时进行分页（pagination）或者加入限制（limit）。HTTP协议支持分页（Pagination）操作，在Header中使用 Link 即可。
7. 使用正确的HTTP Status Code表示访问状态：HTTP/1.1: Status Code Definitions
8. 在返回结果用明确易懂的文本（String。注意返回的错误是要给人看的，避免用 1001 这种错误信息），而且适当地加入注释。
9. 关于安全：自己的接口就用https，加上一个key做一次hash放在最后即可。考虑到国情，HTTPS在无线网络里不稳定，可以使用Application Level的加密手段把整个HTTP的payload加密。有兴趣的朋友可以用手机连上电脑的共享Wi-Fi，然后用Charles监听微信的网络请求（发照片或者刷朋友圈）。
如果是平台的API，可以用成熟但是复杂的OAuth2，新浪微博这篇：授权机制说明
各端的具体实现
如上面的图所示，Server统一提供一套RESTful API，web+ios+android作为同等公民调用API。各端发展到现在，都有一套比较成熟的框架来帮开发者事半功倍。
-- Server --
推荐： Spring MVC 或者 Jersey 或者 Play Framework
教程：
Getting Started · Building a RESTful Web Service
-- Android --
推荐： RetroFit ( Retrofit ) 或者 Volley ( mcxiaoke/android-volley · GitHub Google官方的被block，就不贴了 )
教程：
Retrofit โ€” Getting Started and Create an Android Client
快速Android开发系列网络篇之Retrofit
-- iOS --
推荐：RestKit ( RestKit/RestKit · GitHub )
教程：
Developing RESTful iOS Apps with RestKit
-- Web --
推荐随便搞！可以用重量级的AngularJS，也可以用轻量级 Backbone + jQuery 等。
教程：http://blog.javachen.com/2015/01/06/build-app-with-spring-boot-and-gradle/
参考：
[1]: Some REST best practices
[2]: GitHub API v3
[3]: tlhunter/consumer-centric-api-design · GitHub

㈧ 微博api开放了哪些功能用过的简单介绍一下，谢谢！

微博开放平台是一个基于新浪微博客系统的开放的信息订阅、分享与交流平台。微博开放平台为您提供了海量的微博信息、粉丝关系、以及随时随地发生的信息裂变式传播渠道。您可以登录平台并创建应用，使用微博平台提供的接口，创建有趣的应用或者让您的网站具有更强的社交特性。 用微博账号登录经过简单的代码整合，并在您的网站上放置微博登录按钮，您的网站用户就能够使用微博账号进行登录。网站可以获取当前用户的用户名、头像图片、当前用户的粉丝和关注对象列表。您可以整合现有的用户账户系统或者直接替换成微博的账户系统，帮助您提升网站的用户注册量和提升网站访问数据。 使用OAuth的授权机制进行开发，在网站的显着位置添加“与新浪微博连接”的功能，让用户与能够直接点击并登录。 参考开发介绍：连接微博分享与动态新浪微博现有的用户传播体系非常完整，好友之间通过大量的信息分享带来病毒式的传播。平台提供了分享按钮和动态展现插件，让你仅仅通过几行HTML代码就能够在你的网站上加入社交特性。分享的内容也会在微博网站上展现，用户点击链接后可直接进入相关内容。我们也提供了大量的 API接口帮你实现更多的特性。 内容分享：添加分享到微博的按钮：点击后弹出分享窗口分享内容： 获取微博动态信息：在网站上显示当前网站的微博信息 内容发布与绑定微博平台也提供了发布微博信息的接口，在网站上绑定微博账户后，您可以在网站上整合发布微博信息的功能，让用户在您的网站上发布的信息能够及时的同步到微博网站上。用户的关注者能够及时看到微博内容，可以通过内容的链接或来源链接点击进入网站。用户不仅可以发布文字内容，也可以添加图片。 可以通过账号绑定来实时同步微博信息，让用户的关注者也能够及时了解用户的动态。 在网站上发布信息后，可以直接显示在微博上，微博信息中会显示来源网站，用户可以直接点击进入网站。 参考开发介绍： API接口其他开发环境平台上也可以开发出优秀的桌面客户端应用和手机客户端应用，让用户能够更加方便的发布微博信息和分享内容。相关开发SDK可参见： SDK下载成功案例微博平台上已经发布了多款Web应用、网站、桌面客户端、手机客户端，您可以在这里查看我们的成功案例。取自" http://open.t.sina.com.cn/wiki/index.php/%E5%B9%B3%E5%8F%B0%E6%A6%82%E8%BF%B0"

㈨ 最近云帮手升级之后更新了哪些功能啊

云帮手在6月19日的升级中，优化和修复了以下内容：

1、开放泛解析功能；

2、新增PHP7.2版本及其扩展；

3、windows探针PHP7系列版本新增32位、64位安装及使用；

4、windows探针新增SQL Server 2012版本安装及使用；

5、windows探针新增IIS下强制https功能。

6、探针端优化curl超时问题；

7、优化系统管理计划任务；

8、优化环境管理软件安装流程；

9、优化授权机制；

10、优化站点管理多个站点共享同一个根目录问题;

11、优化安全防护IP黑白名单；

12、优化环境管理MySQL配置；

13、优化远程连接功能。

14、修复已知BUG

欢迎点此体验云帮手

㈩ 有谁用过ecstore啊，复杂不，和ecshop有什么区别

Ecstore是上海商派（da265）推出的是基于新一代的“电子商务解决方案驱动引擎”ECOS开发的企业级开源网上商店系统，系统是基于PHP语言及MYSQL数据库构架开发的跨平台开源程序。目前版本分为：标准版与授权版。

主要运用于帮助企业轻松拓展网上生意；从促销推广到会员引入,从购物流程到订单生成,从订单收订到库房发货,Ecstore 基础版让电子商务各个环节举重若轻。

1、开源不同

Ecstore是商业程序，有开源版本，但是费用相对比较高，但是Ecstore的开发机制是很灵活的，Ecstore 基础版采用SOA（面向服务）架构,采用模块化开发,同时内置完善的API接口,可无缝对接第三方应用插件。

并且Ecstore 标准版引入应用程序接入机制（APP）,用户可自主选择、添加、维护或删除应用程序,如通过安装APP,可便捷实现信任登录功能。

Ecshop：是一款开源免费的通用电子商务平台构建软件，用户可以根据自己的商务特征对ECSHOP进行定制，增加自己商城的特色功能。

但是无论对于开源系统的开发，还是对于不开源系统的开发，都要准寻一个问题，就是不能随意开发。开源和不开源只是相对而说。对于不会代码的人，开源等于不开源。对于会代码的人，不开源，也无任何影响。

2、周边程序不同

Ecstore：只是商派的一个平台，现在商派还基于Ecstore推出了一系列的产品，比如CRM、ERP以及saas部署的易开店等等。一步步完善了电商的生态圈。ecshop：就一个版本。

3、投入方面不同

ECSHOP前期系统投入成本较低，但开发扩展投入成本随着业务量增长，业务复杂度变化，开发成本成倍上升。

ECStore因大量研发资源投入，固前期系统投入成本具备一定门槛，但开发扩展投入成本随着业务量增长，业务复杂度变化，开发成本可控，且外围专业技术服务资源可选性较为广泛。

4、模板设计不同

Ecstore：具有强大的模板自由定制功能，内置多套模板，您可随时更换调整，更可对每个模板进行个性化编辑，不再千人一面;清风设计也可以为您量身定制个性化模板，Ecstore免费开放模板接口，您也可以自行设计、使用全新模板。并且Ecstore的模板支持可视化编辑，很方便用户操作。

ECSHOP：对Dreamweaver模板机制提供完美支持。可使用Dreamweaver制作和查看自己的模板。同时程序提供对模板显示内容控制。

如可以在页面上灵活添加指定分类的商品，或指定品牌的商品等。可随意调整广告的显示，而无需手动修改模板。

5、搜索优化

Ecstore：标准版针对搜索引擎进行优化,结合用户自定义URL等手段,在基本描述内容外,根据系统页面分布,

针对性增加nofollow、noindex等SEO标签,引导搜索引擎蜘蛛爬行,避免商品分类等内容重复度较高页面出现重复,极大提升SEO效果。

ECShop：在SEO（搜索引擎优化）上，独家支持两种 URL 重写方式，并且是同类软件中第一家支持 google / yahoo / microsoft 三家共同发布的 sitemaps 0.9 网站索引规范，能够为站点被搜索引擎收录做到最大限度的支持和帮助。

6、数据承载

Ecstore：支持日常2500万PV/日，峰值5000万PV/日，强大的负载能力。

Ecshop：支持日常2500PV/日，峰值5000PV/日。

7、促销模式

ECstore：拥有业内领先的促销引擎，可结合商品、订单属性，实现千变万化的促销规则,默认可支持近200种促销规则实例，更可支持订单重量、商品类型、商品数量等等数百种条件组合。

ECSHOP：提供了积分、红包、赠品，夺宝奇兵等7种促销方法。

8、常规功能

Ecstore：控制面板立足于“系统配置、数据管理、地区管理、支付管理和配送设置” 等,做到准确到位,全局管控；订单系统Ecstore拥有先进订单管理系统,从“订单确认、订单指派、单据管理,到售后服务管理”,结构清晰、逻辑规范,用户轻松上手。

Ecshop：针对常规功能尤其是后台管理和购物流程，ECShop进行了更简洁的设计，实现更好的用户体验。

9、多接触点用户移动触屏体验管理

ECstore：移动触屏组件采用最新的HTML5技术，能够根据手机终端的不同型号进行应用的自动适配，完全各种电子销售渠道的自动延伸和扩展，在不同的终端带给用户一致的用户体验；

微信商城基于微信平台，让微信5亿用户更了解企业品牌，减少宣传成本，建立企业与消费者、客户的一对一互动和沟通，提供更好的促销、推广、宣传、售后等服务，打造更具影响力的品牌形象。

Ecshop：无

10、性能方面

Ecstore：基于ShopEx自主研发的新一代电子商务引擎ECOS,提供更加安全稳定的底层架构,全方位优化系统架构,同时引入HTML静态生成技术和多级缓存技术,减轻服务器负担,使得前台响应速度和系统负载能力得到极大的提升。

通过大量的测试表明,即使有较大的访问量和数据处理时,Ecstore依然能流畅的提供各项日程服务,即使因营销推广如秒杀等活动造成瞬时大流量,配合ShopEx救援服务依然能确保电商平台的有序运作。

Ecshop：通过优化代码与数据库结构，配合ecshop独家设计的缓存机制，在不考虑网速的情况下，网店动态页面与纯静态页面访问速度相当。

11、价格

Ecstore：是商业的电子商务软件，必须要购买他们的授权才能使用，最低的一个版本是快速启动版，授权费是6.8W，其他更高阶的版本，几万到几十万不等。

Ecshop：可以免费下载使用，但是不能用于商业，如果需要用于商业的话，需要购买他们的授权，授权费是5000元。

shopex和ecshop是目前国内流行的两款电商软件。

(10)php授权机制扩展阅读：

Ecstore秉承了ShopEx产品一贯技术领先的理念,融合了ShopEx在电子商务领域多年的行业经验,采用模块化开发,内置完善的API接口,无缝对接第三方应用插件,提供安全、稳定的底层架构,可为企业提供快速搭建品牌旗舰在线零售平台,以及扩充多渠道销售的解决方案。

Ecstore采用Object-ResourceMap设计,独立的认证授权机制,严格安全的角色访问控制,对核心代码进行多级加密,对数据提供全方位、高级别的防范保护,真正确保数据安全、登录安全、支付安全、资金安全、管理安全。

同时采用云主机集群化的服务器部署,以及提供全程主机运维服务,更有增值运维服务提供应用安全扫描、配置性能优化、安全加固以及营销推广活动造成的大流量救援服务。

Ecstore基于ShopEx自主研发的新一代电子商务引擎ECOS,提供更加安全稳定的底层架构,全方位优化系统架构,同时引入HTML静态生成技术和多级缓存技术,减轻服务器负担,使得前台响应速度和系统负载能力得到极大的提升。