转：https://www.ruanyifeng.com/blog/2016/04/) CORS是一个W3C标准，全称是”跨域资源共享”（Cross-origin resource sharing）。 它允许浏览器向跨源服务器，发出[XMLHttpRequest]请求，从而克服了AJAX只能[同源]使用的限制。 本文详细介绍CORS的内部机制。 一、简介 CORS需要浏览器和服务器同时支持。目前，所有浏览器都支持该功能，IE浏览器不能低于IE10。 整个CORS通信过程，都是浏览器自动完成，不需要用户参与。对于开发者来说，CORS通信与同源的AJAX通信没有差别，代码完全一样。浏览器一旦发现AJAX请求跨源，就会自动添加一些附加的头信息，有时还会多出一次附加的请求，但用户不会有感觉。 因此，实现CORS通信的关键是服务器。只要服务器实现了CORS接口，就可以跨源通信。 二、两种请求 浏览器将CORS请求分成两类：简单请求（simple request）和非简单请求（not-so-simple request）。 只要同时满足以下两大条件，就属于简单请求。 （1) 请求方法是以下三种方法之一： HEAD GET POST （2）HTTP的头信息不超出以下几种字段： Accept Accept-Language Content-Language Last-Event-ID Content-Type：只限于三个值application/x-www-form-urlencoded、multipart/form-data、text/plain 这是为了兼容表单（form），因为历史上表单一直可以发出跨域请求。AJAX 的跨域设计就是，只要表单可以发，AJAX 就可以直接发。 凡是不同时满足上面两个条件，就属于非简单请求。 浏览器对这两种请求的处理，是不一样的。 三、简单请求 3.1 基本流程 对于简单请求，浏览器直接发出CORS请求。具体来说，就是在头信息之中，增加一个Origin字段。 下面是一个例子，浏览器发现这次跨源AJAX请求是简单请求，就自动在头信息之中，添加一个Origin字段。 上面的头信息中，Origin字段用来说明，本次请求来自哪个源（协议 + 域名 + 端口）。服务器根据这个值，决定是否同意这次请求。 如果Origin指定的源，不在许可范围内，服务器会返回一个正常的HTTP回应。浏览器发现，这个回应的头信息没有包含Access-Control-Allow-Origin字段（详见下文），就知道出错了，从而抛出一个错误，被XMLHttpRequest的onerror回调函数捕获。注意，这种错误无法通过状态码识别，因为HTTP回应的状态码有可能是200。 如果Origin指定的域名在许可范围内，服务器返回的响应，会多出几个头信息字段。 上面的头信息之中，有三个与CORS请求相关的字段，都以Access-Control-开头。 （1）Access-Control-Allow-Origin 该字段是必须的。它的值要么是请求时Origin字段的值，要么是一个*，表示接受任意域名的请求。 （2）Access-Control-Allow-Credentials 该字段可选。它的值是一个布尔值，表示是否允许发送Cookie。默认情况下，Cookie不包括在CORS请求之中。设为true，即表示服务器明确许可，Cookie可以包含在请求中，一起发给服务器。这个值也只能设为true，如果服务器不要浏览器发送Cookie，删除该字段即可。 （3）Access-Control-Expose-Headers 该字段可选。CORS请求时，XMLHttpRequest对象的getResponseHeader()方法只能拿到6个基本字段：Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma。如果想拿到其他字段，就必须在Access-Control-Expose-Headers里面指定。上面的例子指定，getResponseHeader(‘FooBar’)可以返回FooBar字段的值。 3.2 withCredentials 属性 上面说到，CORS请求默认不发送Cookie和HTTP认证信息。如果要把Cookie发到服务器，一方面要服务器同意，指定Access-Control-Allow-Credentials字段。 另一方面，开发者必须在AJAX请求中打开withCredentials属性。 […]

1.在tomcat安装目录bin文件夹下shift右键在当前文件夹打开命令窗口 2.输入 service.bat install name安装服务 name为你想安装的tomcat服务名 3.service.bat uninstall 卸载服务 4.自启动在service文件下倒数几行 echo The service ‘%SERVICE_NAME%’ has been installed. 这句是输出服务安装成功,在这之前加一句 sc config %SERVICE_NAME% start= auto

在Linux系统下配置service启动和关闭 1， 通过命令cd /etc/init.d文件夹下2， 再通过命令 vim tomcat10 进入vim编辑界面3，用过 i键 现在把下面代码贴入编辑界面 shell脚本如下 （文件不能执行，请执行该命令）给文件添加权限，使得脚本文件可以执行，命令为： chmod u+x /etc/rc.d/init.d/tomcat 4, 将文件加入到服务队列中 5,查看tomcat 文件是否加入服务列表成功 6,设置服务开机自启动 7,重启

在catalina.sh上面的注释中提到了新的修改方法 Do not set the variables in this script. Instead put them into a scriptrem setenv.sh in CATALINA_BASE/bin to keep your customizations separate. 所以新建setenv.sh，并在其中配置即可 开启远程访问 打开若没有则新建 内容为： 性能调优参数 -XX:AutoBoxCacheMax JAVA进程启动的时候,会加载rt.jar这个核心包的,rt.jar包里的Integer自然也是被加载到JVM中,Integer里面有一个IntegerCache缓存,如下: IntegerCache有一个静态代码块,JVM在加载Integer这个类时,会优先加载静态的代码。当JVM进程启动完毕后, -128 ~ +127 范围的数字会被缓存起来,调用valueOf方法的时候,如果是这个范围内的数字,则直接从缓存取出。超过这个范围的,就只能构造新的Integer对象了。 因此可以根据实际情况把AutoBoxCacheMax的值设置的大一些 -XX:+AlwaysPreTouch JAVA进程启动的时候,虽然我们可以为JVM指定合适的内存大小,但是这些内存操作系统并没有真正的分配给JVM,而是等JVM访问这些内存的时候,才真正分配,这样会造成以下问题。1、GC的时候,新生代的对象要晋升到老年代的时候,需要内存,这个时候操作系统才真正分配内存,这样就会加大young gc的停顿时间;2、可能存在内存碎片的问题。 可以在JVM启动的时候,配置 参数,这样JVM就会先访问所有分配给它的内存,让操作系统把内存真正的分配给JVM.后续JVM就可以顺畅的访问内存了。 GC参数 Java 8 JAVA 1.8用的垃圾收集算法还是CMS,下文提到的参数都是针对CMS的。 CMSInitiatingOccupancyFraction 垃圾收集线程会跟应用的线程一起并行的工作,万一垃圾收集线程在工作的时候,老年代内存不足怎么办?因此最好还是提前启动CMS来收集垃圾(CMS GC)。可以通过设置 那么当老年代堆空间的使用率达到75%的时候就开始执行垃圾回收,CMSInitiatingOccupancyFraction默认值是92%,这个就太大了。CMSInitiatingOccupancyFraction参数必须跟下面两个参数一起使用才能生效的。 MaxTenuringThreshold 新生代是使用copy算法来进行垃圾回收的, 默认情况下,当新生代执行了15次young gc后,如果还有对象存活在Survivor区中,那么就可以直接将这些对象晋升到老年代,但是由于新生代使用copy算法,如果Survivor区存活的对象太久的话,Survivor区存活的对象就越多,这个就会影响copy算法的性能,使得young gc停顿的时间加长,建议设置成6。 […]

参考： http://blog.csdn.net/zj52hm/article/details/51980194 http://blog.csdn.net/wuliu_forever/article/details/52607177 https://www.cnblogs.com/dengyungao/p/7542604.html https://www.cnblogs.com/ysocean/p/6893446.html#_label1 常用配置详解 1 目录结构 /bin：脚本文件目录。 /common/lib：存放所有web项目都可以访问的公共jar包（使用Common类加载器加载）。 /conf：存放配置文件，最重要的是server.xml。 /logs：存放日志文件。 /server/webapps：来管理Tomcat-web服务用的。仅对TOMCAT可见，对所有的WEB APP都不可见（使用Catalina类加载器加载）。 /shared/lib：仅对所有WEB APP可见，对TOMCAT不可见（使用Shared类加载器加载）。 /temp：Tomcat运行时候存放临时文件用的。 /webapps：web应用发布目录。 /work：Tomcat把各种由jsp生成的servlet文件放在这个目录下。删除后，启动时会自动创建。 2 配置文件 server.xml：主要的配置文件。 web.xml：缺省的web app配置， WEB-INF/web.xml会覆盖该配置。 context.xml：不清楚跟server.xml里面的context是否有关系。 server.xml配置 server标签 port：指定一个端口，这个端口负责监听关闭tomcat的请求。 shutdown：指定向端口发送的命令字符串。 service标签 name：指定service的名字。 Connector(表示客户端和service之间的连接)标签 port：指定服务器端要创建的端口号，并在这个端口监听来自客户端的请求。 minProcessors：服务器启动时创建的处理请求的线程数。 maxProcessors：最大可以创建的处理请求的线程数。 enableLookups：如果为true，则可以通过调用request.getRemoteHost()进行DNS查询来得到远程客户端的实际主机名，若为false则不进行DNS查询，而是返回其ip地址。 redirectPort：指定服务器正在处理http请求时收到了一个SSL传输请求后重定向的端口号。 acceptCount：指定当所有可以使用的处理请求的线程数都被使用时，可以放到处理队列中的请求数，超过这个数的请求将不予处理。 connectionTimeout：指定超时的时间数(以毫秒为单位)。 Engine(表示指定service中的请求处理机，接收和处理来自Connector的请求)标签 defaultHost：指定缺省的处理请求的主机名，它至少与其中的一个host元素的name属性值是一样的。 Context(表示一个web应用程序，通常为WAR文件，关于WAR的具体信息见servlet规范)标签 docBase：该web应用的文档基准目录（Document Base，也称为Context Root），或者是WAR文件的路径。可以使用绝对路径，也可以使用相对于context所属的Host的appBase路径。 path：表示此web应用程序的url的前缀，这样请求的url为http://localhost:8080/path/。 reloadable：这个属性非常重要，如果为true，则tomcat会自动检测应用程序的/WEB-INF/lib和/WEB-INF/classes目录的变化，自动装载新的应用程序，我们可以在不重起tomcat的情况下改变应用程序。 useNaming：如果希望Catalina为该web应用使能一个JNDI InitialContext对象，设为true。该InitialialContext符合J2EE平台的约定，缺省值为true。 workDir：Context提供的临时目录的路径，用于servlet的临时读/写。利用javax.servlet.context.tempdir属性，servlet可以访问该目录。如果没有指定，使用$CATALINA_HOME/work下一个合适的目录。 swallowOutput：如果该值为true，System.out和System.err的输出被重定向到web应用的logger。如果没有指定，缺省值为false debug：与这个Engine关联的Logger记录的调试信息的详细程度。数字越大，输出越详细。如果没有指定，缺省为0。 host(表示一个虚拟主机)标签 name：指定主机名。 […]

转载：感谢原作者 一、d还是不d php有memcached和memcache两个类似组件 为什么他选第二个不行？其实php的这2个组件还是有点区别的： 简单来说： memcache 是 pecl 扩展库版本，原生支持php，出现更早，是老前辈； memcached 是 libmemcached 版本，出现较后，是新一代，因此也更加完善，推荐使用。 Ps：如果想更深入了解，可以搜索下 memcache vs memcached 其实，我们这种小网站的话，二选一即可，这点QPS还不至于纠结。不过一旦选择了，安装的时候就要注意区分，一对一配套安装，别搞的牛头不对马嘴，出现上面那位仁兄的困惑（后文有相关说明）。 这里，我果断选择了带d的，继续分享。 二、部署memcached 1、安装memcached Ps：这里的memcached是指Mencached的服务端，用来处理缓存数据，名字也是容易混淆。 下面2种安装方式任选其一： ①、在线安装 #Centos直接使用yum安装即可，其他系统自行搜索安装命令，比如ubuntuyum -y install memcached​#启动memcachedservice memcached start​#开机启动chkconfig memcached on ②、编译安装 相比在线安装，很多时候编译安装更加灵活，非常类似Windows平台的自定义安装或绿色安装，推荐熟悉 Linux 系统的朋友使用： #从官方下载最新源码包wget http://memcached.org/files/memcached-1.4.25.tar.gz​#解压开始编译安装tar xzvf memcached-1.4.15.tar.gzcd memcached-1.4.15./configure –prefix=/usr/local/memcachedmake && make installcd ..​#设置环境ln -s /usr/local/memcached/bin/memcached /usr/bin/memcachedcp scripts/memcached.sysv /etc/init.d/memcached​#改为监听127.0.0.1，并关闭UDP连接方式，若为远程服务调用或不需要的话请跳过此行sed -i ‘s/OPTIONS=””/OPTIONS=”-l 127.0.0.1 -U […]

1.全等匹配： 2.普通匹配： 3.正则匹配： 4.普通匹配和正则匹配之间的匹配关系说明： 步骤详细说明： 1.匹配到全等匹配时，终止后续所有匹配，直接返回；2.步骤一未匹配上时，然后遍历所有的普通匹配，按照最长匹配原则找到最满足的匹配项，如果匹配项前面有^~符号，则终止后续正则匹配，采用该匹配项；反之则继续后续的正则匹配3.步骤一二都未匹配上时，此时进行正则匹配，找到第一个满足的正则匹配项，直接返回，若都不满足，则返回步骤二中的最长匹配项（所以说正则匹配和loaction的顺序有关系）

高性能的实践方案 1、集群部署，通过负载均衡减轻单机压力。 2、多级缓存，包括静态数据使用CDN、本地缓存、分布式缓存等，以及对缓存场景中的热点key、缓存穿透、缓存并发、数据一致性等问题的处理。 3、分库分表和索引优化，以及借助搜索引擎解决复杂查询问题。 4、考虑NoSQL数据库的使用，比如HBase、TiDB等，但是团队必须熟悉这些组件，且有较强的运维能力。 5、异步化，将次要流程通过多线程、MQ、甚至延时任务进行异步处理。 6、限流，需要先考虑业务是否允许限流（比如秒杀场景是允许的），包括前端限流、Nginx接入层的限流、服务端的限流。 7、对流量进行削峰填谷，通过MQ承接流量。 8、并发处理，通过多线程将串行逻辑并行化。 9、预计算，比如抢红包场景，可以提前计算好红包金额缓存起来，发红包时直接使用即可。 10、缓存预热，通过异步任务提前预热数据到本地缓存或者分布式缓存中。 11、减少IO次数，比如数据库和缓存的批量读写、RPC的批量接口支持、或者通过冗余数据的方式干掉RPC调用。 12、减少IO时的数据包大小，包括采用轻量级的通信协议、合适的数据结构、去掉接口中的多余字段、减少缓存key的大小、压缩缓存value等。 13、程序逻辑优化，比如将大概率阻断执行流程的判断逻辑前置、For循环的计算逻辑优化，或者采用更高效的算法。 14、各种池化技术的使用和池大小的设置，包括HTTP请求池、线程池（考虑CPU密集型还是IO密集型设置核心参数）、数据库和Redis连接池等。 15、JVM优化，包括新生代和老年代的大小、GC算法的选择等，尽可能减少GC频率和耗时。 16、锁选择，读多写少的场景用乐观锁，或者考虑通过分段锁的方式减少锁冲突。 上述方案无外乎从计算和 IO 两个维度考虑所有可能的优化点，需要有配套的监控系统实时了解当前的性能表现，并支撑你进行性能瓶颈分析，然后再遵循二八原则，抓主要矛盾进行优化。 高可用的实践方案 1、对等节点的故障转移，Nginx和服务治理框架均支持一个节点失败后访问另一个节点。 2、非对等节点的故障转移，通过心跳检测并实施主备切换（比如redis的哨兵模式或者集群模式、MySQL的主从切换等）。 3、接口层面的超时设置、重试策略和幂等设计。 4、降级处理：保证核心服务，牺牲非核心服务，必要时进行熔断；或者核心链路出问题时，有备选链路。 5、限流处理：对超过系统处理能力的请求直接拒绝或者返回错误码。 6、MQ场景的消息可靠性保证，包括producer端的重试机制、broker侧的持久化、consumer端的ack机制等。 7、灰度发布，能支持按机器维度进行小流量部署，观察系统日志和业务指标，等运行平稳后再推全量。 8、监控报警：全方位的监控体系，包括最基础的CPU、内存、磁盘、网络的监控，以及Web服务器、JVM、数据库、各类中间件的监控和业务指标的监控。 9、灾备演练：类似当前的“混沌工程”，对系统进行一些破坏性手段，观察局部故障是否会引起可用性问题。 高可用的方案主要从冗余、取舍、系统运维3个方向考虑，同时需要有配套的值班机制和故障处理流程，当出现线上问题时，可及时跟进处理。 高扩展的实践方案 1、合理的分层架构：比如上面谈到的互联网最常见的分层架构，另外还能进一步按照数据访问层、业务逻辑层对微服务做更细粒度的分层（但是需要评估性能，会存在网络多一跳的情况）。 2、存储层的拆分：按照业务维度做垂直拆分、按照数据特征维度进一步做水平拆分（分库分表）。 3、业务层的拆分：最常见的是按照业务维度拆（比如电商场景的商品服务、订单服务等），也可以按照核心接口和非核心接口拆，还可以按照请求源拆（比如To C和To B，APP和H5）。