起源

Web刀耕火种的时代，创业型小项目非常之多，不分前后端，页面由 JSP、PHP 等工程师在服务端生成，浏览器负责展现。基本上是服务端给什么浏览器就展现什么，展现的控制在 Web Server 层。

Token Auth的优点

Token机制相对于Cookie机制又有什么好处呢？

• 支持跨域访问: Cookie是不允许垮域访问的，这一点对Token机制是不存在的，前提是传输的用户认证信息通过HTTP头传输.
• 无状态(也称：服务端可扩展行):Token机制在服务端不需要存储session信息，因为Token 自身包含了所有登录用户的信息，只需要在客户端的cookie或本地介质存储状态信息.
• 更适用CDN: 可以通过内容分发网络请求你服务端的所有资料（如：javascript，HTML,图片等），而你的服务端只要提供API即可.
• 去耦: 不需要绑定到一个特定的身份验证方案。Token可以在任何地方生成，只要在你的API被调用的时候，你可以进行Token生成调用即可.
• 更适用于移动应用: 当你的客户端是一个原生平台（iOS, Android，Windows 8等）时，Cookie是不被支持的（你需要通过Cookie容器进行处理），这时采用Token认证机制就会简单得多。
• CSRF:因为不再依赖于Cookie，所以你就不需要考虑对CSRF（跨站请求伪造）的防范。
• 性能: 一次网络往返时间（通过数据库查询session信息）总比做一次HMACSHA256计算 的Token验证和解析要费时得多.
• 不需要为登录页面做特殊处理: 如果你使用Protractor 做功能测试的时候，不再需要为登录页面做特殊处理.
• 基于标准化:你的API可以采用标准化的 JSON Web Token (JWT). 这个标准已经存在多个后端库（.NET, Ruby, Java,Python, PHP）和多家公司的支持（如：Firebase,Google, Microsoft）.
• 防止XSS攻击：由于前后端分离，cookie设置不了HttpOnly，所以会存在XSS攻击的可能。使用JWT授权机制的话，其header传递的方式可一定程度上阻止XSS. ###

简介

```php /**

• 日期 奖品 权重 库存
• 3.1 1元 5000 5000
• 3.1 2元 1000 1000
• 3.1 3元 500 500
• 3.1 5元 100 100
• 3.1 iphone6s 1 1
• 3.1 未中奖 59409 59409 **/ //奖品库存 //未中奖：假设设定抽10次中一次, 未中奖权重 = 抽检概率导数奖品数-奖品数 = 106601-6601 = 59409 $awardStockMap = [“1元”=>5000,”2元”=>1000,”3元”=>500,”5元”=>100,”iphone”=>1, “未中奖”=>59409]; $awardWeightMap = $awardStockMap;//奖品权重，此处默认为库存 asort($awardWeightMap);

什么叫虚拟化

绝大多数人目前理解的虚拟化技术就是把操作系统和硬件分离，一个硬件能够同时运行多个操作系统认为就是虚拟化技术，其实这只是虚拟化技术中很小的一个部分，和很初级的阶段。

测试环境

提供测试人员使用，代码分支除了可以使用master分支外，其他的分支也是可以的。

ELK由Elasticsearch、Logstash和Kibana三部分组件组成；

敏感信息禁止缓存

• Cache-Control This response header, introduced in HTTP 1.1, may contain one or more directives, each carrying a specific caching semantic, and instructing HTTP clients and proxies on how to treat the response being annotated by the header. My recommendation is to format the header as follows: cache-control: no-cache, no-store, must-revalidate. These three directives pretty much instruct clients and intermediary proxies not to use a previously cached response, not to store the response, and that even if the response is somehow cached, the cache must be revalidated on the origin server.
• Pragma: no-cache For backwards-compatibility with HTTP 1.0, you will want to include this header as well. Some HTTP clients, especially intermediary proxies, still might not fully support HTTP 1.1 and so will not correctly handle the Cache-Control header mentioned above. Use Pragma: no-cache to ensure that these older clients do not cache your response.
• Expires: -1 This header specifies a timestamp after which the response is considered stale. By specifying -1, instead of an actual future time, you ensure that clients immediately treat this response as stale and avoid caching.

例子

那还是10年前，还没有12306的年代，大家买票只能去火车站买。因为大家都要过年回家，都还不想等，火车站只有一个，窗口只有那么多，头疼啊。更头疼的是，排到窗口的那个人，各种挑剔，不要贵的，不要晚上的，不要站票……跟售票员各种墨迹，后面的人更加着急，一个个义愤填膺，骂爹骂娘。

现在假设整个城市就只有1个火车，1个售票员，每个乘客咨询售票员后需要思考1分钟再决定买哪趟车的票。

1. 异步 ：在买票的人咨询后，需要思考1分钟，马上靠边站，但不用重新排队，什么时候想清楚可以立马去跟售票员去买票。在该人站在旁边思考的时候，后面的人赶紧上去接着买。这时候队伍是很快的挪动的，没有阻塞，售票员的最大化的效率。
2. 多线程：火车站开n个窗口（但还是只有一个人售票），外面同时排n个队，售票员回答咨询者问题后，立马马上去下个窗口，然后继续轮换到下个窗口…..哪个窗口的人决定好了，售票员立马过去买给他。这个时候乘客比较简单，但万一那个队伍有人思考半天纠结，后面的人就悲剧了。
3. 并行：复制n个火车站，同时卖票，买票能力大大增强。大家也可以哪个火车站人少，就去那个买票。

结论

1. 异步和多线程其实效率差不多，但是开的窗口不多例如3个，同时有很多人都是去花5分钟，而不是1分钟去纠结的时候，多线程效率实际是低于异步的，因为售票员还是常遇到3个队伍同时卡在那纠结不能买票的时候。
2. 这2个概念拿来对比也有点不合适，因为他们不是一个概念，多线程的目的还是为了实现异步，多线程应该是一种实现异步的手段。异步应该去跟同步比较才对。
3. 多线程比较简单，但需要增设窗口，增加成本，且售票员比较累这类似apache下php，和node.js下javascript的关系，一个是多线程，但是是阻塞的，另外一个是单线程异步非阻塞的。php的方案比较符合常规思维，但比较费内存，node.js非阻塞，用较少的资源就能完成同样的任务，但编程比较费神。
4. 并行，类似同时利用多核cpu的各个核去计算。并发可分为伪并发、真并发。前者例如单核处理器的并发，后者发是指多核处理器的并发。
5. 终极办法是并行计算，并且每个cpu下进行异步计算，这样你的每个核都充分利用。只不过对编程要求太高了太高了，如果不是密集型计算，例如大型有限元计算（多采用并发），或者服务器同时处理上千的访问（多采用异步或者多线程），还是老老实实的用传统的办法吧，毕竟常规程序的计算量对现在的硬件来说，问题都不大。

内核线程和用户线程

内核线程

• 内核线程又称为守护进程，内核线程的调度由内核负责，一个内核线程处于阻塞状态时不影响其他的内核线程，因为其是调度的基本单位。这与用户线程是不一样的；
• 这些线程可以在全系统内进行资源的竞争；
• 内核空间内为每一个内核支持线程设置了一个线程控制块（TCB），内核根据该控制块，感知线程的存在，并进行控制。在一定程度上类似于进程，只是创建、调度的开销要比进程小。有的统计是1：10。
• 内核线程切换由内核控制，当线程进行切换的时候，由用户态转化为内核态。切换完毕要从内核态返回用户态，即存在用户态和内核态之间的转换，比如多核cpu，还有win线程的实现。

  优点

  在多处理器系统中，内核能够同时调度同一进程中多个线程并行执行到多个处理器中；如果进程中的一个线程被阻塞，内核可以调度同一个进程中的另一个线程；内核支持线程具有很小的数据结构和堆栈，线程的切换比较快，切换开销小；内核本身也可以使用多线程的方式来实现。

缺点

即使CPU在同一个进程的多个线程之间切换，也需要陷入内核，因此其速度和效率不如用户级线程。

用户线程

• 用户线程在用户空间中实现，内核并没有直接对用户线程进程调度，内核的调度对象和传统进程一样，还是进程（用户进程）本身，内核并不能看到用户线程，内核并不知道用户线程的存在。
• 不需要内核支持而在用户程序中实现的线程，其不依赖于操作系统核心，应用进程利用线程库提供创建、同步、调度和管理线程的函数来控制用户线程。
• 内核资源的分配仍然是按照进程（用户进程）进行分配的；各个用户线程只能在进程内进行资源竞争。
• 用户级线程内核的切换由用户态程序自己控制内核切换（通过系统调用来获得内核提供的服务）,不需要内核干涉，少了进出内核态的消耗，但不能很好的利用多核Cpu。目前Linux pthread大体是这么做的。
• 每个用户线程并不具有自身的线程上下文。因此，就线程的同时执行而言，任意给定时刻每个进程只能够有一个线程在运行，而且只有一个处理器内核会被分配给该进程。

优点

线程的切换无需陷入内核，故切换开销小，速度非常快；

缺点

系统调用的阻塞问题：对应用程序来讲，同一进程中只能同时有一个线程在运行，一个线程的阻塞将导致整个进程中所有线程的阻塞；由于这里的处理器时间片分配是以进程为基本单位，所以每个线程执行的时间相对减少。

异步IO

考虑到CPU和IO之间巨大的速度差异，一个任务在执行的过程中大部分时间都在等待IO操作，单进程单线程模型会导致别的任务无法并行执行，因此，我们才需要多进程模型或者多线程模型来支持多任务并发执行。

现代操作系统对IO操作已经做了巨大的改进，最大的特点就是支持异步IO。如果充分利用操作系统提供的异步IO支持，就可以用单进程单线程模型来执行多任务，这种全新的模型称为事件驱动模型，Nginx就是支持异步IO的Web服务器，它在单核CPU上采用单进程模型就可以高效地支持多任务。在多核CPU上，可以运行多个进程（数量与CPU核心数相同），充分利用多核CPU。由于系统总的进程数量十分有限，因此操作系统调度非常高效。用异步IO编程模型来实现多任务是一个主要的趋势。

对应到Python语言，单进程的异步编程模型称为协程，有了协程的支持，就可以基于事件驱动编写高效的多任务程序。我们会在后面讨论如何编写协程。

协程看上去也是子程序，但执行过程中，在子程序内部可中断，然后转而执行别的子程序，在适当的时候再返回来接着执行。

这也解释了为什么xrange叫做迭代生成器, 因为它返回一个迭代器, 而这个迭代器实现了Iterator接口.

调用迭代器的方法一次, 其中的代码运行一次.例如, 如果你调用$range->rewind(), 那么xrange()里的代码就会运行到控制流第一次出现yield的地方. 而函数内传递给yield语句的返回值可以通过$range->current()获取.

协程的支持是在迭代生成器的基础上, 增加了可以回送数据给生成器的功能(调用者发送数据给被调用的生成器函数). 这就把生成器到调用者的单向通信转变为两者之间的双向通信.

要理解协程，首先要理解： 代码是代码，函数是函数。函数包裹的代码赋予了这段代码附加的意义：有参数，有返回值，当函数调用另个函数的时候，必须等这个函数返回，当前函数才能返回，这就构成了后进先出，也就是stack。

而协程包裹的代码，不是函数，不完全遵守函数的这些附加的意义，协程执行到某个点，他yield，而不是return，再次调用协程的时候，会在上次yeild的点继续执行。

所以协程违背了通常操作系统和x86的cpu认定的代码执行方式，也就是stack的这种执行方式，需要运行环境（比如php，python的yield和golang的goroutine）自己调度，来实现你所要求的这种代码执行的语义。

php在php5.5的时候引入了generator和coroutine,从核心上提出了一种方法去写不阻塞的IO,当然这和node的event loop还是有比较大的区别的,它的主要理念是：把几个大任务分别分成多个小步轮流执行，有某个小任务在等待系统io的话，就跳过它，执行下一个小任务，这样总体提升了代码的效率。

要理解是什么是“用户态的线程”，必然就要先理解什么是“内核态的线程”。 内核态的线程是由操作系统来进行调度的，在切换线程上下文时，要先保存上一个线程的上下文，然后执行下一个线程，当条件满足时，切换回上一个线程，并恢复上下文。 协程也是如此，只不过，用户态的线程不是由操作系统来调度的，而是由程序员来调度的，是在用户态的。

yield这个关键字就是用来产生中断, 并保存当前的上下文的, 比如说程序的一段代码是访问远程服务器，那这个时候CPU就是空闲的，就用yield让出CPU，接着执行下一段的代码，如果下一段代码还是访问除CPU以外的其它资源，还可以调用yield让出CPU. 继续往下执行，这样就可以用同步的方式写异步的代码了.

协程的好处有哪些

没有啥复杂的东西，考虑清楚需求，就可以很自然的衍生出这些解决方案。

• 一开始大家想要同一时间执行那么三五个程序，大家能一块跑一跑。特别是UI什么的，别一上计算量比较大的玩意就跟死机一样。于是就有了并发，从程序员的角度可以看成是多个独立的逻辑流。内部可以是多cpu并行，也可以是单cpu时间分片，能快速的切换逻辑流，看起来像是大家一块跑的就行。
• 但是一块跑就有问题了。我计算到一半，刚把多次方程解到最后一步，你突然插进来，我的中间状态咋办，我用来储存的内存被你覆盖了咋办？所以跑在一个cpu里面的并发都需要处理上下文切换的问题。进程就是这样抽象出来个一个概念，搭配虚拟内存、进程表之类的东西，用来管理独立的程序运行、切换。
• 后来一电脑上有了好几个cpu，好咧，大家都别闲着，一人跑一进程。就是所谓的并行。
• 因为程序的使用涉及大量的计算机资源配置，把这活随意的交给用户程序，非常容易让整个系统分分钟被搞跪，资源分配也很难做到相对的公平。所以核心的操作需要陷入内核(kernel)，切换到操作系统，让老大帮你来做。
• 有的时候碰着I/O访问，阻塞了后面所有的计算。空着也是空着，老大就直接把CPU切换到其他进程，让人家先用着。当然除了I\O阻塞，还有时钟阻塞等等。一开始大家都这样弄，后来发现不成，太慢了。为啥呀，一切换进程得反复进入内核，置换掉一大堆状态。进程数一高，大部分系统资源就被进程切换给吃掉了。后来搞出线程的概念，大致意思就是，这个地方阻塞了，但我还有其他地方的逻辑流可以计算，这些逻辑流是共享一个地址空间的，不用特别麻烦的切换页表、刷新TLB，只要把寄存器刷新一遍就行，能比切换进程开销少点。
• 如果连时钟阻塞、 线程切换这些功能我们都不需要了，自己在进程里面写一个逻辑流调度的东西。那么我们即可以利用到并发优势，又可以避免反复系统调用，还有进程切换造成的开销，分分钟给你上几千个逻辑流不费力。这就是用户态线程。
• 从上面可以看到，实现一个用户态线程有两个必须要处理的问题：一是碰着阻塞式I\O会导致整个进程被挂起；二是由于缺乏时钟阻塞，进程需要自己拥有调度线程的能力。如果一种实现使得每个线程需要自己通过调用某个方法，主动交出控制权。那么我们就称这种用户态线程是协作式的，即是协程。本质上协程就是用户空间下的线程。

通俗易懂的回答:让原来要使用异步+回调方式写的非人类代码,可以用看似同步的方式写出来

说线程性能不好的很多是因为没有设计好导致大量的锁、切换、等待，这些很多都是应用层的问题。而协程因为是非抢占式，所以需要用户自己释放使用权来切换到其他协程，因此同一时间其实只有一个协程拥有运行权，相当于单线程的能力

最大的优势就是协程极高的执行效率。因为子程序切换不是线程切换，而是由程序自身控制，因此，没有线程切换的开销，和多线程比，线程数量越多，协程的性能优势就越明显。

第二大优势就是不需要多线程的锁机制，因为只有一个线程，也不存在同时写变量冲突，在协程中控制共享资源不加锁，只需要判断状态就好了，所以执行效率比多线程高很多。

因为协程是一个线程执行，那怎么利用多核CPU呢？最简单的方法是多进程+协程，既充分利用多核，又充分发挥协程的高效率，可获得极高的性能。

协程并不是趋势，只是一种解决问题的思维方式而已。它并不能解决所有的问题，例如对于高密集计算，软实时的系统现在的协程还存在很大的问题。协程也不是只能简单的处理一些 IO 问题。

数组：