[索引使用 ]的搜索结果

...就数据表的规范化、表索引优化、容量设计、事务处理等诸多方面与程序员进行卓有成效的沟通和协作，那么日常的前台管理工作将会变得大为轻松,因为在某种意义上，数据库管理系统就相当于操作系统，在系统中占有同样重要的位置。 这正是SQL SERVER等数据库管理系统和dBASEX、ACCESS等数据库文件系统的本质区别，所以，对数据库管理系统操作能力的强弱在某种程度上也折射出了网管的水平——个人认为，称得上优秀的Admin,至少应该是一个称职的DBA（数据库管理员）。 下面以SQL SERVER（下称 SQLS）为例，将数据库管理中难于理解的“索引原理”问题给各位朋友作一个深入浅出的介绍。其他的数据库管理系统如Oracle、Sybase等，朋友们可以融会贯通，举一反三。 一、数据表的基本结构 建立数据库的目的是管理大量数据，而建立索引的目的就是提高数据检索效率，改善数据库工作性能，提高数据访问速度。对于索引，我们要知其然，更要知其所以然，关键在于认识索引的工作原理，才能更好的管理索引。 为认识索引工作原理，首先有必要对数据表的基本结构作一次全面的复习。 SQLS当一个新表被创建之时，系统将在磁盘中分配一段以8K为单位的连续空间，当字段的值从内存写入磁盘时，就在这一既定空间随机保存，当一个8K用完的时候，SQLS指针会自动分配一个8K的空间。这里，每个8K空间被称为一个数据页（Page），又名页面或数据页面，并分配从0-7的页号,每个文件的第0页记录引导信息，叫文件头（File header）；每8个数据页（64Ｋ）的组合形成扩展区（Extent），称为扩展。全部数据页的组合形成堆（Heap）。 SQLS规定行不能跨越数据页，所以，每行记录的最大数据量只能为8K。这就是char和varchar这两种字符串类型容量要限制在8K以内的原因，存储超过8K的数据应使用text类型，实际上，text类型的字段值不能直接录入和保存，它只是存储一个指针，指向由若干8K的文本数据页所组成的扩展区，真正的数据正是放在这些数据页中。 页面有空间页面和数据页面之分。 当一个扩展区的8个数据页中既包含了空间页面又包括了数据或索引页面时，称为混合扩展（Mixed Extent）,每张表都以混合扩展开始；反之，称为一致扩展（Uniform Extent），专门保存数据及索引信息。 表被创建之时，SQLS在混合扩展中为其分配至少一个数据页面，随着数据量的增长，SQLS可即时在混合扩展中分配出7个页面，当数据超过8个页面时，则从一致扩展中分配数据页面。 空间页面专门负责数据空间的分配和管理，包括：PFS页面（Page free space）：记录一个页面是否已分配、位于混合扩展还是一致扩展以及页面上还有多少可用空间等信息；GAM页面（Global allocation map）和SGAM页面(Secodary global allocation map)：用来记录空闲的扩展或含有空闲页面的混合扩展的位置。SQLS综合利用这三种类型的页面文件在必要时为数据表创建新空间； 数据页或索引页则专门保存数据及索引信息，SQLS使用4种类型的数据页面来管理表或索引：它们是IAM页、数据页、文本/图像页和索引页。 在WINDOWS中，我们对文件执行的每一步操作，在磁盘上的物理位置只有系统（system）才知道；SQL SERVER沿袭了这种工作方式，在插入数据的过程中，不但每个字段值在数据页面中的保存位置是随机的，而且每个数据页面在“堆”中的排列位置也只有系统（system）才知道。 这是为什么呢？众所周知，OS之所以能管理DISK，是因为在系统启动时首先加载了文件分配表：FAT（File Allocation Table），正是由它管理文件系统并记录对文件的一切操作，系统才得以正常运行；同理，作为管理系统级的SQL SERVER,也有这样一张类似FAT的表存在，它就是索引分布映像页：IAM（Index Allocation Map）。 IAM的存在，使SQLS对数据表的物理管理有了可能。 IAM页从混合扩展中分配，记录了8个初始页面的位置和该扩展区的位置，每个IAM页面能管理512,000个数据页面，如果数据量太大，SQLS也可以增加更多的IAM页，可以位于文件的任何位置。第一个IAM页被称为FirstIAM,其中记录了以后的IAM页的位置。 数据页和文本/图像页互反，前者保存非文本/图像类型的数据，因为它们都不超过8K的容量，后者则只保存超过8K容量的文本或图像类型数据。而索引页顾名思义，保存的是与索引结构相关的数据信息。了解页面的问题有助我们下一步准确理解SQLS维护索引的方式，如页拆分、填充因子等。 二、索引的基本概念 索引是一种特殊类型的数据库对象，它与表有着密切的联系。 索引是为检索而存在的。如一些书籍的末尾就专门附有索引，指明了某个关键字在正文中的出现的页码位置，方便我们查找，但大多数的书籍只有目录，目录不是索引，只是书中内容的排序，并不提供真正的检索功能。可见建立索引要单独占用空间；索引也并不是必须要建立的，它们只是为更好、更快的检索和定位关键字而存在。 再进一步说，我们要在图书馆中查阅图书，该怎么办呢？图书馆的前台有很多叫做索引卡片柜的小柜子，里面分了若干的类别供我们检索图书，比如你可以用书名的笔画顺序或者拼音顺序作为查找的依据，你还可以从作者名的笔画顺序或拼音顺序去查询想要的图书，反正有许多检索方式，但有一点很明白，书库中的书并没有按照这些卡片柜中的顺序排列——虽然理论上可以这样做，事实上，所有图书的脊背上都人工的粘贴了一个特定的编号①，它们是以这个顺序在排列。索引卡片中并没有指明这本书摆放在书库中的第几个书架的第几本，仅仅指明了这个特定的编号。管理员则根据这一编号将请求的图书返回到读者手中。这是很形象的例子，以下的讲解将会反复用到它。 SQLS在安装完成之后，安装程序会自动创建master、model、tempdb等几个特殊的系统数据库，其中master是SQLS的主数据库，用于保存和管理其它系统数据库、用户数据库以及SQLS的系统信息，它在SQLS中的地位与WINDOWS下的注册表相当。 master中有一个名为sysindexes的系统表，专门管理索引。SQLS查询数据表的操作都必须用到它，毫无疑义，它是本文主角之一。 查看一张表的索引属性，可以在查询分析器中使用以下命令：select from sysindexes where id=object_id(‘tablename’) ；而要查看表的索引所占空间的大小，可以使用系统存储过程命令：sp_spaceused tablename，其中参数tablename为被索引的表名。 三、平衡树 如果你通过书后的索引知道了一个关键字所在的页码，你有可能通过随机的翻寻，最终到达正确的页码。但更科学更快捷的方法是：首先把书翻到大概二分之一的位置，如果要找的页码比该页的页码小，就把书向前翻到四分之一处，否则，就把书向后翻到四分之三的地方，依此类推，把书页续分成更小的部分，直至正确的页码。这叫“两分法”，微软在官方教程MOC里另有一种说法：叫B树（B-Tree，Balance Tree），即平衡树。 一个表索引由若干页面组成，这些页面构成了一个树形结构。B树由“根”（root）开始，称为根级节点，它通过指向另外两个页，把一个表的记录从逻辑上分成两个部分：“枝”—--非叶级节点（Non-Leaf Level）；而非叶级节点又分别指向更小的部分：“叶”——叶级节点（Leaf Level）。根节点、非叶级节点和叶级节点都位于索引页中，统称为索引节点，属于索引页的范筹。这些“枝”、“叶”最终指向了具体的数据页（Page）。在根级节点和叶级节点之间的叶又叫数据中间页。 “根”（root）对应了sysindexes表的Root字段，其中记载了非叶级节点的物理位置（即指针）；非叶级节点位于根节点和叶节点之间，记载了指向叶级节点的指针；而叶级节点则最终指向数据页。这就是“平衡树”。 四、聚集索引和非聚集索引 从形式上而言，索引分为聚集索引（Clustered Indexes）和非聚集索引（NonClustered Indexes）。 聚集索引相当于书籍脊背上那个特定的编号。如果对一张表建立了聚集索引，其索引页中就包含着建立索引的列的值（下称索引键值），那么表中的记录将按照该索引键值进行排序。比如，我们如果在“姓名”这一字段上建立了聚集索引，则表中的记录将按照姓名进行排列；如果建立了聚集索引的列是数值类型的，那么记录将按照该键值的数值大小来进行排列。 非聚集索引用于指定数据的逻辑顺序，也就是说，表中的数据并没有按照索引键值指定的顺序排列，而仍然按照插入记录时的顺序存放。其索引页中包含着索引键值和它所指向该行记录在数据页中的物理位置，叫做行定位符（RID：Row ID）。好似书后面的的索引表，索引表中的顺序与实际的页码顺序也是不一致的。而且一本书也许有多个索引。比如主题索引和作者索引。 SQL Server在默认的情况下建立的索引是非聚集索引，由于非聚集索引不对表中的数据进行重组，而只是存储索引键值并用一个指针指向数据所在的页面。一个表如果没有聚集索引时,理论上可以建立249个非聚集索引。每个非聚集索引提供访问数据的不同排序顺序。 五、数据是怎样被访问的 若能真正理解了以上索引的基础知识，那么再回头来看索引的工作原理就简单和轻松多了。 （一）SQLS怎样访问没有建立任何索引数据表： Heap译成汉语叫做“堆”，其本义暗含杂乱无章、无序的意思，前面提到数据值被写进数据页时，由于每一行记录之间并没地有特定的排列顺序，所以行与行的顺序就是随机无序的，当然表中的数据页也就是无序的了，而表中所有数据页就形成了“堆”，可以说，一张没有索引的数据表，就像一个只有书柜而没有索引卡片柜的图书馆，书库里面塞满了一堆乱七八糟的图书。当读者对管理员提交查询请求后，管理员就一头钻进书库，对照查找内容从头开始一架一柜的逐本查找，运气好的话，在第一个书架的第一本书就找到了，运气不好的话，要到最后一个书架的最后一本书才找到。 SQLS在接到查询请求的时候，首先会分析sysindexes表中一个叫做索引标志符(INDID: Index ID)的字段的值，如果该值为0，表示这是一张数据表而不是索引表，SQLS就会使用sysindexes表的另一个字段——也就是在前面提到过的FirstIAM值中找到该表的IAM页链——也就是所有数据页集合。 这就是对一个没有建立索引的数据表进行数据查找的方式，是不是很没效率？对于没有索引的表，对于一“堆”这样的记录，SQLS也只能这样做，而且更没劲的是，即使在第一行就找到了被查询的记录，SQLS仍然要从头到尾的将表扫描一次。这种查询称为“遍历”，又叫“表扫描”。 可见没有建立索引的数据表照样可以运行，不过这种方法对于小规模的表来说没有什么太大的问题，但要查询海量的数据效率就太低了。 （二）SQLS怎样访问建立了非聚集索引的数据表： 如前所述，非聚集索引可以建多个,具有B树结构，其叶级节点不包含数据页，只包含索引行。假定一个表中只有非聚集索引，则每个索引行包含了非聚集索引键值以及行定位符（ROW ID,RID），他们指向具有该键值的数据行。每一个RID由文件ID、页编号和在页中行的编号组成。 当INDID的值在2-250之间时，意味着表中存在非聚集索引页。此时，SQLS调用ROOT字段的值指向非聚集索引B树的ROOT，在其中查找与被查询最相近的值，根据这个值找到在非叶级节点中的页号，然后顺藤摸瓜，在叶级节点相应的页面中找到该值的RID，最后根据这个RID在Heap中定位所在的页和行并返回到查询端。 例如：假定在Lastname上建立了非聚集索引，则执行Select From Member Where Lastname=’Ota’时，查询过程是：①SQLS查询INDID值为2；②立即从根出发，在非叶级节点中定位最接近Ota的值“Martin”，并查到其位于叶级页面的第61页；③仅在叶级页面的第61页的Martin下搜寻Ota的RID，其RID显示为N∶706∶4，表示Lastname字段中名为Ota的记录位于堆的第707页的第4行，N表示文件的ID值，与数据无关；④根据上述信息，SQLS立马在堆的第 707页第4行将该记录“揪”出来并显示于前台（客户端）。视表的数据量大小，整个查询过程费时从百分之几毫秒到数毫秒不等。 在谈到索引基本概念的时候，我们就提到了这种方式： 图书馆的前台有很多索引卡片柜，里面分了若干的类别，诸如按照书名笔画或拼音顺序、作者笔画或拼音顺序等等，但不同之处有二：① 索引卡片上记录了每本书摆放的具体位置——位于某柜某架的第几本——而不是“特殊编号”；② 书脊上并没有那个“特殊编号”。管理员在索引柜中查到所需图书的具体位置（RID）后，根据RID直接在书库中的具体位置将书提出来。 显然，这种查询方式效率很高，但资源占用极大，因为书库中书的位置随时在发生变化，必然要求管理员花费额外的精力和时间随时做好索引更新。 （三）SQLS怎样访问建立了聚集索引的数据表： 在聚集索引中，数据所在的数据页是叶级，索引数据所在的索引页是非叶级。 查询原理和上述对非聚集索引的查询相似，但由于记录是按照聚集索引中索引键值进行排序，换句话说，聚集索引的索引键值也就是具体的数据页。 这就好比书库中的书就是按照书名的拼音在排序，而且也只按照这一种排序方式建立相应的索引卡片，于是查询起来要比上述只建立非聚集索引的方式要简单得多。仍以上面的查询为例： 假定在Lastname字段上建立了聚集索引，则执行Select From Member Where Lastname=’Ota’时，查询过程是：①SQLS查询INDID值为1，这是在系统中只建立了聚集索引的标志；②立即从根出发，在非叶级节点中定位最接近Ota的值“Martin”，并查到其位于叶级页面的第120页；③在位于叶级页面第120页的Martin下搜寻到Ota条目，而这一条目已是数据记录本身；④将该记录返回客户端。 这一次的效率比第二种方法更高，以致于看起来更美，然而它最大的优点也恰好是它最大的缺点——由于同一张表中同时只能按照一种顺序排列，所以在任何一种数据表中的聚集索引只能建立一个；并且建立聚集索引需要至少相当于源表120%的附加空间，以存放源表的副本和索引中间页！ 难道鱼和熊掌就不能兼顾了吗？办法是有的。 （四）SQLS怎样访问既有聚集索引、又有非聚集索引的数据表： 如果我们在建立非聚集索引之前先建立了聚集索引的话，那么非聚集索引就可以使用聚集索引的关键字进行检索，就像在图书馆中，前台卡片柜中的可以有不同类别的图书索引卡，然而每张卡片上都载明了那个特殊编号——并不是书籍存放的具体位置。这样在最大程度上既照顾了数据检索的快捷性，又使索引的日常维护变得更加可行，这是最为科学的检索方法。 也就是说，在只建立了非聚集索引的情况下，每个叶级节点指明了记录的行定位符（RID）；而在既有聚集索引又有非聚集索引的情况下，每个叶级节点所指向的是该聚集索引的索引键值，即数据记录本身。 假设聚集索引建立在Lastname上，而非聚集索引建立在Firstname上，当执行Select From Member Where Firstname=’Mike’时，查询过程是：①SQLS查询INDID值为2；②立即从根出发，在Firstname的非聚集索引的非叶级节点中定位最接近Mike的值“Jose”条目；③从Jose条目下的叶级页面中查到Mike逻辑位置——不是RID而是聚集索引的指针；④根据这一指针所指示位置，直接进入位于Lastname的聚集索引中的叶级页面中到达Mike数据记录本身；⑤将该记录返回客户端。 这就完全和我们在“索引的基本概念”中讲到的现实场景完全一样了，当数据发生更新的时候，SQLS只负责对聚集索引的健值驾以维护，而不必考虑非聚集索引，只要我们在ID类的字段上建立聚集索引，而在其它经常需要查询的字段上建立非聚集索引，通过这种科学的、有针对性的在一张表上分别建立聚集索引和非聚集索引的方法，我们既享受了索引带来的灵活与快捷，又相对规避了维护索引所导致的大量的额外资源消耗。 六、索引的优点和不足 索引有一些先天不足：1：建立索引，系统要占用大约为表的1.2倍的硬盘和内存空间来保存索引。2：更新数据的时候，系统必须要有额外的时间来同时对索引进行更新，以维持数据和索引的一致性——这就如同图书馆要有专门的位置来摆放索引柜，并且每当库存图书发生变化时都需要有人将索引卡片重整以保持索引与库存的一致。 当然建立索引的优点也是显而易见的：在海量数据的情况下，如果合理的建立了索引，则会大大加强SQLS执行查询、对结果进行排序、分组的操作效率。 实践表明，不恰当的索引不但于事无补，反而会降低系统性能。因为大量的索引在进行插入、修改和删除操作时比没有索引花费更多的系统时间。比如在如下字段建立索引应该是不恰当的：1、很少或从不引用的字段；2、逻辑型的字段，如男或女(是或否)等。 综上所述，提高查询效率是以消耗一定的系统资源为代价的，索引不能盲目的建立，必须要有统筹的规划，一定要在“加快查询速度”与“降低修改速度”之间做好平衡，有得必有失，此消则彼长。这是考验一个DBA是否优秀的很重要的指标。 至此，我们一直在说SQLS在维护索引时要消耗系统资源，那么SQLS维护索引时究竟消耗了什么资源？会产生哪些问题？究竟应该才能优化字段的索引？ 在上篇中，我们就索引的基本概念和数据查询原理作了详细阐述，知道了建立索引时一定要在“加快查询速度”与“降低修改速度”之间做好平衡，有得必有失，此消则彼长。那么，SQLS维护索引时究竟怎样消耗资源？应该从哪些方面对索引进行管理与优化？以下就从七个方面来回答这些问题。 一、页分裂 微软MOC教导我们：当一个数据页达到了8K容量，如果此时发生插入或更新数据的操作，将导致页的分裂(又名页拆分)： 1、有聚集索引的情况下：聚集索引将被插入和更新的行指向特定的页，该页由聚集索引关键字决定； 2、只有堆的情况下：只要有空间就可以插入新的行，但是如果我们对行数据的更新需要更多的空间，以致大于了当前页的可用空间，行就被移到新的页中，并且在原位置留下一个转发指针，指向被移动的新行，如果具有转发指针的行又被移动了，那么原来的指针将重新指向新的位置； 3、如果堆中有非聚集索引，那么尽管插入和更新操作在堆中不会发生页分裂，但是在非聚集索引上仍然产生页分裂。 无论有无索引，大约一半的数据将保留在老页面，而另一半将放入新页面，并且新页面可能被分配到任何可用的页。所以，频繁页分裂，后果很严重，将使物理表产生大量数据碎片，导致直接造成I/O效率的急剧下降，最后，停止SQLS的运行并重建索引将是我们的唯一选择! 二、填充因子 然而在“混沌之初”，就可以在一定程度上避免不愉快出现：在创建索引时，可以为这个索引指定一个填充因子，以便在索引的每个叶级页面上保留一定百分比的空间，将来数据可以进行扩充和减少页分裂。填充因子是从0到100的百分比数值，设为100时表示将数据页填满。只有当不会对数据进行更改时(例如只读表中)才用此设置。值越小则数据页上的空闲空间越大，这样可以减少在索引增长过程中进行页分裂的需要，但这一操作需要占用更多的硬盘空间。 填充因子只在创建索引时执行，索引创建以后，当表中进行数据的添加、删除或更新时，是不会保持填充因子的，如果想在数据页上保持额外的空间，则有悖于使用填充因子的本意，因为随着数据的输入，SQLS必须在每个页上进行页拆分，以保持填充因子指定的空闲空间。因此，只有在表中的数据进行了较大的变动，才可以填充数据页的空闲空间。这时，可以从容的重建索引，重新指定填充因子，重新分布数据。 反之，填充因子指定不当，就会降低数据库的读取性能，其降低量与填充因子设置值成反比。例如，当填充因子的值为50时，数据库的读取性能会降低两倍！所以，只有在表中根据现有数据创建新索引，并且可以预见将来会对这些数据进行哪些更改时，设置填充因子才有意义。 三、两道数学题 假定数据库设计没有问题，那么是否象上篇中分析的那样，当你建立了众多的索引，在查询工作中SQLS就只能按照“最高指示”用索引处理每一个提交的查询呢？答案是否定的！ 上篇“数据是怎样被访问的”章节中提到的四种索引方案只是一种静态的、标准的和理论上的分析比较，实际上，将在外，军令有所不从，SQLS几乎完全是“自主”的决定是否使用索引或使用哪一个索引！ 这是怎么回事呢？ 让我们先来算一道题：如果某表的一条记录在磁盘上占用1000字节(1K)的话，我们对其中10字节的一个字段建立索引，那么该记录对应的索引大小只有10字节(0.01K)。上篇说过，SQLS的最小空间分配单元是“页（Page）”，一个页面在磁盘上占用8K空间，所以一页只能存储8条“记录”，但可以存储800条“索引”。现在我们要从一个有8000条记录的表中检索符合某个条件的记录(有Where子句)，如果没有索引的话，我们需要遍历8000条×1000字节/8K字节=1000个页面才能够找到结果。如果在检索字段上有上述索引的话，那么我们可以在8000条×10字节/8K字节=10个页面中就检索到满足条件的索引块，然后根据索引块上的指针逐一找到结果数据块，这样I/O访问量肯定要少得多。 然而有时用索引还不如不用索引快！ 同上，如果要无条件检索全部记录(不用Where子句)，不用索引的话，需要访问8000条×1000字节/8K字节=1000个页面；而使用索引的话，首先检索索引，访问8000条×10字节/8K字节=10个页面得到索引检索结果，再根据索引检索结果去对应数据页面，由于是检索全部数据，所以需要再访问8000条×1000字节/8K字节=1000个页面将全部数据读取出来，一共访问了1010个页面，这显然不如不用索引快。 SQLS内部有一套完整的数据索引优化技术，在上述情况下，SQLS会自动使用表扫描的方式检索数据而不会使用任何索引。那么SQLS是怎么知道什么时候用索引，什么时候不用索引的呢？因为SQLS除了维护数据信息外，还维护着数据统计信息！ 四、统计信息 打开企业管理器，单击“Database”节点，右击Northwind数据库→单击“属性”→选择“Options”选项卡，观察“Settings”下的各项复选项，你发现了什么？ 从Settings中我们可以看到，在数据库中，SQLS将默认的自动创建和更新统计信息，这些统计信息包括数据密度和分布信息，正是它们帮助SQLS确定最佳的查询策略：建立查询计划和是否使用索引以及使用什么样的索引。 在创建索引时，SQLS会创建分布数据页来存放有关索引的两种统计信息：分布表和密度表。查询优化器使用这些统计信息估算使用该索引进行查询的成本(Cost)，并在此基础上判断该索引对某个特定查询是否有用。 随着表中的数据发生变化，SQLS自动定期更新这些统计信息。采样是在各个数据页上随机进行。从磁盘读取一个数据页后，该数据页上的所有行都被用来更新统计信息。统计信息更新的频率取决于字段或索引中的数据量以及数据更改量。比如，对于有一万条记录的表，当1000个索引键值发生改变时，该表的统计信息便可能需要更新，因为1000 个值在该表中占了10%，这是一个很大的比例。而对于有1千万条记录的表来说，1000个索引值发生更改的意义则可以忽略不计，因此统计信息就不会自动更新。 至于它们帮助SQLS建立查询计划的具体过程，限于篇幅，这里就省略了，请有兴趣的朋友们自己研究。 顺便多说一句，SQLS除了能自动记录统计信息之外，还可以记录服务器中所发生的其它活动的详细信息，包括I/O 统计信息、CPU 统计信息、锁定请求、T-SQL 和 RPC 统计信息、索引和表扫描、警告和引发的错误、数据库对象的创建/除去、连接/断开、存储过程操作、游标操作等等。这些信息的读取、设置请朋友们在SQLS联机帮助文档(SQL Server Books Online)中搜索字符串“Profiler”查找。 五、索引的人工维护 上面讲到,某些不合适的索引将影响到SQLS的性能,随着应用系统的运行,数据不断地发生变化,当数据变化达到某一个程度时将会影响到索引的使用。这时需要用户自己来维护索引。 随着数据行的插入、删除和数据页的分裂，有些索引页可能只包含几页数据，另外应用在执行大量I/O的时候，重建非聚聚集索引可以维护I/O的效率。重建索引实质上是重新组织B树。需要重建索引的情况有： 1) 数据和使用模式大幅度变化； 2)排序的顺序发生改变； 3)要进行大量插入操作或已经完成； 4)使用I/O查询的磁盘读次数比预料的要多； 5)由于大量数据修改，使得数据页和索引页没有充分使用而导致空间的使用超出估算； 6)dbcc检查出索引有问题。 六、索引的使用原则 接近尾声的时候，让我们再从另一个角度认识索引的两个重要属性----唯一性索引和复合性索引。 在设计表的时候，可以对字段值进行某些限制，比如可以对字段进行主键约束或唯一性约束。 主键约束是指定某个或多个字段不允许重复，用于防止表中出现两条完全相同的记录，这样的字段称为主键，每张表都可以建立并且只能建立一个主键，构成主键的字段不允许空值。例如职员表中“身份证号”字段或成绩表中“学号、课程编号”字段组合。 而唯一性约束与主键约束类似，区别只在于构成唯一性约束的字段允许出现空值。 建立在主键约束和唯一性约束上的索引，由于其字段值具有唯一性，于是我们将这种索引叫做“唯一性索引”，如果这个唯一性索引是由两个以上字段的组合建立的，那么它又叫“复合性索引”。 注意，唯一索引不是聚集索引，如果对一个字段建立了唯一索引，你仅仅不能向这个字段输入重复的值。并不妨碍你可以对其它类型的字段也建立一个唯一性索引，它们可以是聚集的，也可以是非聚集的。 唯一性索引保证在索引列中的全部数据是唯一的，不会包含冗余数据。如果表中已经有一个主键约束或者唯一性约束，那么当创建表或者修改表时，SQLS自动创建一个唯一性索引。但出于必须保证唯一性，那么应该创建主键约束或者唯一性键约束，而不是创建一个唯一性索引。当创建唯一性索引时，应该认真考虑这些规则：当在表中创建主键约束或者唯一性键约束时， SQLS钭自动创建一个唯一性索引；如果表中已经包含有数据，那么当创建索引时，SQLS检查表中已有数据的冗余性，如果发现冗余值，那么SQLS就取消该语句的执行，并且返回一个错误消息，确保表中的每一行数据都有一个唯一值。 复合索引就是一个索引创建在两个列或者多个列上。在搜索时，当两个或者多个列作为一个关键值时，最好在这些列上创建复合索引。当创建复合索引时，应该考虑这些规则：最多可以把16个列合并成一个单独的复合索引，构成复合索引的列的总长度不能超过900字节，也就是说复合列的长度不能太长；在复合索引中，所有的列必须来自同一个表中，不能跨表建立复合列；在复合索引中，列的排列顺序是非常重要的，原则上，应该首先定义最唯一的列，例如在（COL1，COL2）上的索引与在（COL2，COL1）上的索引是不相同的，因为两个索引的列的顺序不同；为了使查询优化器使用复合索引，查询语句中的WHERE子句必须参考复合索引中第一个列；当表中有多个关键列时，复合索引是非常有用的；使用复合索引可以提高查询性能，减少在一个表中所创建的索引数量。 综上所述，我们总结了如下索引使用原则： 1)逻辑主键使用唯一的成组索引，对系统键（作为存储过程）采用唯一的非成组索引，对任何外键列采用非成组索引。考虑数据库的空间有多大，表如何进行访问，还有这些访问是否主要用作读写。 2)不要索引memo/note 字段，不要索引大型字段（有很多字符），这样作会让索引占用太多的存储空间。 3)不要索引常用的小型表 4)一般不要为小型数据表设置过多的索引，假如它们经常有插入和删除操作就更别这样作了，SQLS对这些插入和删除操作提供的索引维护可能比扫描表空间消耗更多的时间。 七、大结局 查询是一个物理过程，表面上是SQLS在东跑西跑，其实真正大部分压马路的工作是由磁盘输入输出系统(I/O)完成，全表扫描需要从磁盘上读表的每一个数据页，如果有索引指向数据值，则I/O读几次磁盘就可以了。但是，在随时发生的增、删、改操作中，索引的存在会大大增加工作量，因此，合理的索引设计是建立在对各种查询的分析和预测上的，只有正确地使索引与程序结合起来,才能产生最佳的优化方案。 一般来说建立索引的思路是： (1)主键时常作为where子句的条件，应在表的主键列上建立聚聚集索引，尤其当经常用它作为连接的时候。 (2)有大量重复值且经常有范围查询和排序、分组发生的列，或者非常频繁地被访问的列，可考虑建立聚聚集索引。　　 (3)经常同时存取多列，且每列都含有重复值可考虑建立复合索引来覆盖一个或一组查询，并把查询引用最频繁的列作为前导列，如果可能尽量使关键查询形成覆盖查询。 (4)如果知道索引键的所有值都是唯一的，那么确保把索引定义成唯一索引。 (5)在一个经常做插入操作的表上建索引时，使用fillfactor(填充因子)来减少页分裂，同时提高并发度降低死锁的发生。如果在只读表上建索引，则可以把fillfactor置为100。 (6)在选择索引字段时，尽量选择那些小数据类型的字段作为索引键，以使每个索引页能够容纳尽可能多的索引键和指针，通过这种方式，可使一个查询必须遍历的索引页面降到最小。此外，尽可能地使用整数为键值，因为它能够提供比任何数据类型都快的访问速度。 SQLS是一个很复杂的系统，让索引以及查询背后的东西真相大白，可以帮助我们更为深刻的了解我们的系统。一句话，索引就象盐，少则无味多则咸。 本篇文章为转载内容。原文链接：https://blog.csdn.net/qq_28052907/article/details/75194926。 该文由互联网用户投稿提供，文中观点代表作者本人意见，并不代表本站的立场。 作为信息平台，本站仅提供文章转载服务，并不拥有其所有权，也不对文章内容的真实性、准确性和合法性承担责任。 如发现本文存在侵权、违法、违规或事实不符的情况，请及时联系我们，我们将第一时间进行核实并删除相应内容。

...，并返回给前端，前端使用该 url 进行视频的在线播放。 在线学习完整的测试流程：媒资信息的上传、选择、发布到前端门户、搜索门户测试，在线学习的播放视频。 目录 内容会比较多，小伙伴门可以根据目录进行按需查阅。 文章目录 😎 知识点概览 目录 一、学习页面：查询课程计划 0x01 需求分析 0x02 Api接口 0x03 服务端开发 Controller Service 测试 0x04 前端开发 配置NGINX虚拟主机 前端 API 方法 前端 API 方法调用 测试 二、学习页面：获取视频播放地址 0x01 需求分析 0x02 课程发布：储存媒资信息 需求分析 数据模型 Dao Service 测试 0x03 Logstash：扫描课程计划媒资 创建索引 创建模板文件 配置 mysql.conf 启动 logstash.bat Logstash多实例运行 0x04 搜素服务：查询课程媒资接口 需求分析 Api接口定义 Service Controller 测试 三、在线学习：接口开发 0x01 需求分析 0x02 搭建开发环境 0x03 Api接口 0x04 服务端开发 需求分析 搜索服务注册Eureka 搜索服务客户端 自定义错误代码 Service Controller 测试 0x05 前端开发 需求分析 api方法 配置代理 视频播放页面 简单的测试 完整的测试 1、上传文件 一些问题 ~~方案1：删除本地分块文件重新尝试上传~~ 方案2：检查前端提交的MD5值是否正确 2、为课程计划选择媒资信息 3、前端门户测试 四、待完善的一些功能 😁 认识作者 一、学习页面：查询课程计划 0x01 需求分析 到目前为止，我们已可以编辑课程计划信息并上传课程视频，下一步我们要实现在线学习页面动态读取章节对应的视频并进行播放。在线学习页面所需要的信息有两类： 课程计划信息 课程学习信息（视频地址、学习进度等） 如下图： 在线学习集成媒资管理的需求如下： 1、在线学习页面显示课程计划 2、点击课程计划播放该课程计划对应的视频 本章节实现学习页面动态显示课程计划，进入不同课程的学习页面右侧动态显示当前课程的课程计划。 0x02 Api接口 课程计划信息从哪里获取？ 在课程发布完成后会自动发布到一个 course_pub 的表中，logstash 会自动将课程发布后的信息自动采集到 ES 索引库中，这些信息也包含课程计划信息。 所以考虑性能要求，课程发布后对课程的查询统一从 ES 索引库中查询。 前端通过请求 搜索服务 获取课程信息，需要单独在 搜索服务 中定义课程信息查询接口。 本接口接收课程id，查询课程所有信息返回给前端。 我们在搜素服务 API 下添加以下方法 @ApiOperation("根据id搜索课程发布信息")public Map<String,CoursePub> getdetail(String id); 返回的课程信息为 json 结构：key 为课程id，value 为课程内容。 0x03 服务端开发 在搜索服务中开发查询课程信息接口。 Controller 在搜素服务下添加以下方法 / 根据id搜索课程发布信息 @param id 课程id @return JSON数据/@Override@GetMapping("/getdetail/{id}")public Map<String, CoursePub> getdetail(@PathVariable("id")String id) {return esCourseService.getdetail(id);} Service / 根据id搜索课程发布信息 @param id 课程id @return JSON数据/public Map<String, CoursePub> getdetail(String id) {//设置索引SearchRequest searchRequest = new SearchRequest(es_index);//设置类型searchRequest.types(es_type);//创建搜索源对象SearchSourceBuilder searchSourceBuilder = new SearchSourceBuilder();//设置查询条件,根据id进行查询searchSourceBuilder.query(QueryBuilders.termQuery("id",id));//这里不使用source的原字段过滤,查询所有字段// searchSourceBuilder.fetchSource(new String[]{"name", "grade", "charge","pic"}, newString[]{});//设置搜索源对象searchRequest.source(searchSourceBuilder);//执行搜索SearchResponse searchResponse = null;try {searchResponse = restHighLevelClient.search(searchRequest);} catch (IOException e) {e.printStackTrace();}//获取搜索结果SearchHits hits = searchResponse.getHits();SearchHit[] searchHits = hits.getHits(); //获取最优结果Map<String,CoursePub> map = new HashMap<>();for (SearchHit hit: searchHits) {//从搜索结果中取值并添加到coursePub对象Map<String, Object> sourceAsMap = hit.getSourceAsMap();String courseId = (String) sourceAsMap.get("id");String name = (String) sourceAsMap.get("name");String grade = (String) sourceAsMap.get("grade");String charge = (String) sourceAsMap.get("charge");String pic = (String) sourceAsMap.get("pic");String description = (String) sourceAsMap.get("description");String teachplan = (String) sourceAsMap.get("teachplan");CoursePub coursePub = new CoursePub();coursePub.setId(courseId);coursePub.setName(name);coursePub.setPic(pic);coursePub.setGrade(grade);coursePub.setTeachplan(teachplan);coursePub.setDescription(description);//设置map对象map.put(courseId,coursePub);}return map;} 测试 使用 swagger-ui 或 postman 测试查询课程信息接口。 0x04 前端开发 配置NGINX虚拟主机 学习中心的二级域名为 ucenter.xuecheng.com ，我们在 nginx 中配置 ucenter 虚拟主机。 学成网用户中心server {listen 80;server_name ucenter.xuecheng.com;个人中心location / {proxy_pass http://ucenter_server_pool;} } 前端ucenterupstream ucenter_server_pool{server 127.0.0.1:7081 weight=10;server 127.0.0.1:13000 weight=10;} 在学习中心要调用搜索的 API，使用 Nginx 解决代理，如下图： 在 ucenter 虚拟主机下配置搜索 Api 代理路径 后台搜索（公开api）upstream search_server_pool{server 127.0.0.1:40100 weight=10;} 学成网用户中心server {listen 80;server_name ucenter.xuecheng.com;个人中心location / {proxy_pass http://ucenter_server_pool;}后端搜索服务location /openapi/search/ {proxy_pass http://search_server_pool/search/;} } 前端 API 方法 在学习中心 xc-ui-pc-leanring 对课程信息的查询属于基础常用功能，所以我们将课程查询的 api 方法定义在base 模块下，如下图： 在system.js 中定义课程查询方法： import http from './public'export const course_view = id => {return http.requestGet('/openapi/search/course/getdetail/'+id);} 前端 API 方法调用 在 learning_video.vue 页面中调用课程信息查询接口得到课程计划，将课程计划json 串转成对象。 xc-ui-pc-leanring/src/module/course/page/learning_video.vue 1、定义视图 课程计划 <!--课程计划部分代码--><div class="navCont"><div class="course-weeklist"><div class="nav nav-stacked" v-for="(teachplan_first, index) in teachplanList"><div class="tit nav-justified text-center"><i class="pull-left glyphicon glyphicon-th-list"></i>{ {teachplan_first.pname} }<i class="pull-right"></i></div><li v-if="teachplan_first.children!=null" v-for="(teachplan_second, index) in teachplan_first.children"><i class="glyphicon glyphicon-check"></i><a :href="url" @click="study(teachplan_second.id)">{ {teachplan_second.pname} }</a></li><!-- <div class="tit nav-justified text-center"><i class="pull-left glyphicon glyphicon-th-list"></i>第一章<i class="pull-right"></i></div><li ><i class="glyphicon glyphicon-check"></i><a :href="url" >第一节</a></li>--><!--<li><i class="glyphicon glyphicon-unchecked"></i>为什么分为A、B、C部分</li>--></div></div></div> 课程名称 <div class="top text-center">{ {coursename} }</div> 定义数据对象 data() {return {url:'',//当前urlcourseId:'',//课程idchapter:'',//章节Idcoursename:'',//课程名称coursepic:'',//课程图片teachplanList:[],//课程计划playerOptions: {//播放参数autoplay: false,controls: true,sources: [{type: "application/x-mpegURL",src: ''}]},} } 在 created 钩子方法中获取课程信息 created(){//当前请求的urlthis.url = window.location//课程idthis.courseId = this.$route.params.courseId//章节idthis.chapter = this.$route.params.chapter//查询课程信息systemApi.course_view(this.courseId).then((view_course)=>{if(!view_course || !view_course[this.courseId]){this.$message.error("获取课程信息失败，请重新进入此页面！")return ;} let courseInfo = view_course[this.courseId]console.log(courseInfo)this.coursename = courseInfo.nameif(courseInfo.teachplan){let teachplan = JSON.parse(courseInfo.teachplan);this.teachplanList = teachplan.children;} })}, 测试 在浏览器请求：http://ucenter.xuecheng.com//learning/4028e581617f945f01617f9dabc40000/0 4028e581617f945f01617f9dabc40000：第一个参数为课程 id，测试时从 ES索引库找一个课程 id 0：第二个参数为课程计划 id，此参数用于点击课程计划播放视频。 如果出现跨域问题，但是确定已经配置了跨域，请尝试结束所以 nginx.exe 的进程 和 清空浏览器缓存。 如果还没有解决？重启电脑试试。 二、学习页面：获取视频播放地址 0x01 需求分析 用户进入在线学习页面，点击课程计划将播放该课程计划对应的教学视频。 业务流程如下： 业务流程说明： 1、用户进入在线学习页面，页面请求搜索服务获取课程信息（包括课程计划信息）并且在页面展示。 2、在线学习请求学习服务获取视频播放地址。 3、学习服务校验当前用户是否有权限学习，如果没有权限学习则提示用户。 4、学习服务校验通过，请求搜索服务获取课程媒资信息。 5、搜索服务请求ElasticSearch获取课程媒资信息。 为什么要请求 ElasticSearch 查询课程媒资信息？ 出于性能的考虑，公开查询课程信息从搜索服务查询，分摊 mysql 数据库的访问压力。 什么时候将课程媒资信息存储到 ElasticSearch 中？ 课程媒资信息是在课程发布的时候存入 ElasticSearch，因为课程发布后课程信息将基本不再修改。 0x02 课程发布：储存媒资信息 需求分析 课程媒资信息是在课程发布的时候存入 ElasticSearch 索引库，因为课程发布后课程信息将基本不再修改，具体的业务流程如下。 1、课程发布，向课程媒资信息表写入数据。 1）根据课程 id 删除 teachplanMediaPub 中的数据 2）根据课程 id 查询 teachplanMedia 数据 3）将查询到的 teachplanMedia 数据插入到 teachplanMediaPub 中 2、Logstash 定时扫描课程媒资信息表，并将课程媒资信息写入索引库。 数据模型 在 xc_course 数据库创建课程计划媒资发布表： CREATE TABLE teachplan_media_pub (teachplan_id varchar(32) NOT NULL COMMENT '课程计划id',media_id varchar(32) NOT NULL COMMENT '媒资文件id',media_fileoriginalname varchar(128) NOT NULL COMMENT '媒资文件的原始名称',media_url varchar(256) NOT NULL COMMENT '媒资文件访问地址',courseid varchar(32) NOT NULL COMMENT '课程Id',timestamp timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT'logstash使用',PRIMARY KEY (teachplan_id)) ENGINE=InnoDB DEFAULT CHARSET=utf8 数据模型类如下： package com.xuecheng.framework.domain.course;import lombok.Data;import lombok.ToString;import org.hibernate.annotations.GenericGenerator;import javax.persistence.;import java.io.Serializable;import java.util.Date;@Data@ToString@Entity@Table(name="teachplan_media_pub")@GenericGenerator(name = "jpa-assigned", strategy = "assigned")public class TeachplanMediaPub implements Serializable {private static final long serialVersionUID = -916357110051689485L;@Id@GeneratedValue(generator = "jpa-assigned")@Column(name="teachplan_id")private String teachplanId;@Column(name="media_id")private String mediaId;@Column(name="media_fileoriginalname")private String mediaFileOriginalName;@Column(name="media_url")private String mediaUrl;@Column(name="courseid")private String courseId;@Column(name="timestamp")private Date timestamp;//时间戳} Dao 创建 TeachplanMediaPub 表的 Dao，向 TeachplanMediaPub 存储信息采用先删除该课程的媒资信息，再添加该课程的媒资信息，所以这里定义根据课程 id 删除课程计划媒资方法： public interface TeachplanMediaPubRepository extends JpaRepository<TeachplanMediaPub, String> {//根据课程id删除课程计划媒资信息long deleteByCourseId(String courseId);} 从TeachplanMedia查询课程计划媒资信息 //从TeachplanMedia查询课程计划媒资信息public interface TeachplanMediaRepository extends JpaRepository<TeachplanMedia, String> {List<TeachplanMedia> findByCourseId(String courseId);} Service 编写保存课程计划媒资信息方法，并在课程发布时调用此方法。 1、保存课程计划媒资信息方法 本方法采用先删除该课程的媒资信息，再添加该课程的媒资信息，在 CourseService 下定义该方法 //保存课程计划媒资信息private void saveTeachplanMediaPub(String courseId){//查询课程媒资信息List<TeachplanMedia> byCourseId = teachplanMediaRepository.findByCourseId(courseId);if(byCourseId == null) return; //没有查询到媒资数据则直接结束该方法//将课程计划媒资信息储存到待索引表//删除原有的索引信息teachplanMediaPubRepository.deleteByCourseId(courseId);//一个课程可能会有多个媒资信息,遍历并使用list进行储存List<TeachplanMediaPub> teachplanMediaPubList = new ArrayList<>();for (TeachplanMedia teachplanMedia: byCourseId) {TeachplanMediaPub teachplanMediaPub = new TeachplanMediaPub();BeanUtils.copyProperties(teachplanMedia, teachplanMediaPub);teachplanMediaPubList.add(teachplanMediaPub);}//保存所有信息teachplanMediaPubRepository.saveAll(teachplanMediaPubList);} 2、课程发布时调用此方法 修改课程发布的 coursePublish 方法： ....//保存课程计划媒资信息到待索引表saveTeachplanMediaPub(courseId);//页面urlString pageUrl = cmsPostPageResult.getPageUrl();return new CoursePublishResult(CommonCode.SUCCESS,pageUrl);..... 测试 测试课程发布后是否成功将课程媒资信息存储到 teachplan_media_pub 中，测试流程如下： 1、指定一个课程 2、为课程计划添加课程媒资 3、执行课程发布 4、观察课程计划媒资信息是否存储至 teachplan_media_pub 中 注意：由于此测试仅用于测试发布课程计划媒资信息的功能，可暂时将 cms页面发布的功能暂时屏蔽，提高测试效率。 测试结果如下 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Vrzs5589-1595567273126)(https://qnoss.codeyee.com/20200704_15/image7)] 0x03 Logstash：扫描课程计划媒资 Logstash 定时扫描课程媒资信息表，并将课程媒资信息写入索引库。 创建索引 1、创建 xc_course_media 索引 2、并向此索引创建如下映射 POST: http://localhost:9200/xc_course_media/doc/_mapping {"properties" : {"courseid" : {"type" : "keyword"},"teachplan_id" : {"type" : "keyword"},"media_id" : {"type" : "keyword"},"media_url" : {"index" : false,"type" : "text"},"media_fileoriginalname" : {"index" : false,"type" : "text"} }} 索引创建成功 创建模板文件 在 logstach 的 config 目录文件 xc_course_media_template.json 文件路径为 %ES_ROOT_DIR%/logstash6.8.8/config/xc_course_media_template.json %ES_ROOT_DIR% 为 ElasticSearch 和 logstash 的安装目录 内容如下： {"mappings" : {"doc" : {"properties" : {"courseid" : {"type" : "keyword"},"teachplan_id" : {"type" : "keyword"},"media_id" : {"type" : "keyword"},"media_url" : {"index" : false,"type" : "text"},"media_fileoriginalname" : {"index" : false,"type" : "text"} }},"template" : "xc_course_media"} } 配置 mysql.conf 在logstash的 config 目录下配置 mysql_course_media.conf 文件供 logstash 使用，logstash 会根据 mysql_course_media.conf 文件的配置的地址从 MySQL 中读取数据向 ES 中写入索引。 参考https://www.elastic.co/guide/en/logstash/current/plugins-inputs-jdbc.html 配置输入数据源和输出数据源。 input {stdin {} jdbc {jdbc_connection_string => "jdbc:mysql://localhost:3306/xc_course?useUnicode=true&characterEncoding=utf-8&useSSL=true&serverTimezone=UTC" 数据库信息jdbc_user => "root"jdbc_password => "123123" MYSQL 驱动地址,修改为maven仓库对应的位置jdbc_driver_library => "D:/soft/apache-maven-3.5.4/repository/mysql/mysql-connector-java/5.1.40/mysql-connector-java-5.1.40.jar" the name of the driver class for mysqljdbc_driver_class => "com.mysql.jdbc.Driver"jdbc_paging_enabled => "true"jdbc_page_size => "50000"要执行的sql文件statement_filepath => "/conf/course.sql"statement => "select from teachplan_media_pub where timestamp > date_add(:sql_last_value,INTERVAL 8 HOUR)"定时配置schedule => " "record_last_run => truelast_run_metadata_path => "D:/soft/elasticsearch/logstash-6.8.8/config/xc_course_media_metadata"} } output {elasticsearch {ES的ip地址和端口hosts => "localhost:9200"hosts => ["localhost:9200","localhost:9202","localhost:9203"]ES索引库名称index => "xc_course_media"document_id => "%{teachplan_id}"document_type => "doc"template => "D:/soft/elasticsearch/logstash-6.8.8/config/xc_course_media_template.json"template_name =>"xc_course_media"template_overwrite =>"true"} stdout {日志输出codec => json_lines} } 启动 logstash.bat 启动 logstash.bat 采集 teachplan_media_pub 中的数据，向 ES 写入索引。 logstash.bat -f ../config/mysql_course_media.conf 课程发布成功后，Logstash 会自动参加 teachplan_media_pub 表中新增的数据，效果如下 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ILPBxfXi-1595567273134)(https://qnoss.codeyee.com/20200704_15/image10)] Logstash多实例运行 由于之前我们还启动了一个 Logstash 对课程的发布信息进行采集，所以如果想两个 logstash 实例同时运行，因为每个实例都有一个.lock文件，所以不能使用同一个目录来存放数据，所以我们需要使用 --path.data= 为每个实例指定单独的数据目录，具体的代码如下： 该配置是在windows下进行的 课程发布实例 logstash_start_course_pub.bat @title logstash in course_publogstash.bat -f ..\config\mysql.conf --path.data=../data/course_pub 课程计划媒体发布实例 logstash_start_teachplan_media.bat @title logstash i n teachplan_media_publogstash.bat -f ../config/mysql_course_media.conf --path.data=../data/teachplan_media/ 同时运行效果如下 0x04 搜素服务：查询课程媒资接口 需求分析 搜索服务 提供查询课程媒资接口，此接口供学习服务调用。 Api接口定义 @ApiOperation("根据课程计划查询媒资信息")public TeachplanMediaPub getmedia(String teachplanId); Service 1、配置课程计划媒资索引库等信息 在 application.yml 中配置 xuecheng:elasticsearch:hostlist: ${eshostlist:127.0.0.1:9200} 多个结点中间用逗号分隔course:index: xc_coursetype: docsource_field: id,name,grade,mt,st,charge,valid,pic,qq,price,price_old,status,studymodel,teachmode,expires,pub_time,start_time,end_timemedia:index: xc_course_mediatype: docsource_field: courseid,media_id,media_url,teachplan_id,media_fileoriginalname 2、service 方法开发 在 课程搜索服务 中定义课程媒资查询接口，为了适应后续需求，service 参数定义为数组，可一次查询多个课程计划的媒资信息。 / 根据一个或者多个课程计划id查询媒资信息 @param teachplanIds 课程id @return QueryResponseResult/public QueryResponseResult<TeachplanMediaPub> getmedia(String [] teachplanIds){//设置索引SearchRequest searchRequest = new SearchRequest(media_index);//设置类型searchRequest.types(media_type);//创建搜索源对象SearchSourceBuilder searchSourceBuilder = new SearchSourceBuilder();//源字段过滤String[] media_index_arr = media_field.split(",");searchSourceBuilder.fetchSource(media_index_arr, new String[]{});//查询条件,根据课程计划id查询(可以传入多个课程计划id)searchSourceBuilder.query(QueryBuilders.termsQuery("teachplan_id", teachplanIds));searchRequest.source(searchSourceBuilder);SearchResponse searchResponse = null;try {searchResponse = restHighLevelClient.search(searchRequest);} catch (IOException e) {e.printStackTrace();}//获取结果SearchHits hits = searchResponse.getHits();long totalHits = hits.getTotalHits();SearchHit[] searchHits = hits.getHits();//数据列表List<TeachplanMediaPub> teachplanMediaPubList = new ArrayList<>();for(SearchHit hit:searchHits){TeachplanMediaPub teachplanMediaPub =new TeachplanMediaPub();Map<String, Object> sourceAsMap = hit.getSourceAsMap();//取出课程计划媒资信息String courseid = (String) sourceAsMap.get("courseid");String media_id = (String) sourceAsMap.get("media_id");String media_url = (String) sourceAsMap.get("media_url");String teachplan_id = (String) sourceAsMap.get("teachplan_id");String media_fileoriginalname = (String) sourceAsMap.get("media_fileoriginalname");teachplanMediaPub.setCourseId(courseid);teachplanMediaPub.setMediaUrl(media_url);teachplanMediaPub.setMediaFileOriginalName(media_fileoriginalname);teachplanMediaPub.setMediaId(media_id);teachplanMediaPub.setTeachplanId(teachplan_id);//将对象加入到列表中teachplanMediaPubList.add(teachplanMediaPub);}//构建返回课程媒资信息对象QueryResult<TeachplanMediaPub> queryResult = new QueryResult<>();queryResult.setList(teachplanMediaPubList);queryResult.setTotal(totalHits);return new QueryResponseResult<TeachplanMediaPub>(CommonCode.SUCCESS,queryResult);} Controller / 根据课程计划id搜索发布后的媒资信息 @param teachplanId @return/@GetMapping(value="/getmedia/{teachplanId}")@Overridepublic TeachplanMediaPub getmedia(@PathVariable("teachplanId") String teachplanId) {//为了service的拓展性,所以我们service接收的是数组作为参数,以便后续开发查询多个ID的接口String[] teachplanIds = new String[]{teachplanId};//通过service查询ES获取课程媒资信息QueryResponseResult<TeachplanMediaPub> mediaPubQueryResponseResult = esCourseService.getmedia(teachplanIds);QueryResult<TeachplanMediaPub> queryResult = mediaPubQueryResponseResult.getQueryResult();if(queryResult!=null&& queryResult.getList()!=null&& queryResult.getList().size()>0){//返回课程计划对应课程媒资return queryResult.getList().get(0);} return new TeachplanMediaPub();} 测试 使用 swagger-ui 和 postman 测试课程媒资查询接口。 三、在线学习：接口开发 0x01 需求分析 根据下边的业务流程，本章节完成前端学习页面请求学习服务获取课程视频地址，并自动播放视频。 0x02 搭建开发环境 1、创建数据库 创建 xc_learning 数据库，学习数据库将记录学生的选课信息、学习信息。 导入：资料/xc_learning.sql 2、创建学习服务工程 参考课程管理服务工程结构，创建学习服务工程： 导入：资料/xc-service-learning.zip 项目工程结构如下 0x03 Api接口 此 api 接口是课程学习页面请求学习服务获取课程学习地址。 定义返回值类型： package com.xuecheng.framework.domain.learning.response;import com.xuecheng.framework.model.response.ResponseResult;import com.xuecheng.framework.model.response.ResultCode;import lombok.Data;import lombok.NoArgsConstructor;import lombok.ToString;@Data@ToString@NoArgsConstructorpublic class GetMediaResult extends ResponseResult {public GetMediaResult(ResultCode resultCode, String fileUrl) {super(resultCode);this.fileUrl = fileUrl;}//媒资文件播放地址private String fileUrl;} 定义接口，学习服务根据传入课程 ID、章节 Id(课程计划 ID)来取学习地址。 @Api(value = "录播课程学习管理",description = "录播课程学习管理")public interface CourseLearningControllerApi {@ApiOperation("获取课程学习地址")public GetMediaResult getMediaPlayUrl(String courseId,String teachplanId);} 0x04 服务端开发 需求分析 学习服务根据传入课程ID、章节Id(课程计划ID)请求搜索服务获取学习地址。 搜索服务注册Eureka 学习服务要调用搜索服务查询课程媒资信息，所以需要将搜索服务注册到 eureka 中。 1、查看服务名称是否为 xc-service-search 注意修改application.xml中的服务名称：spring:application:name: xc‐service‐search 2、配置搜索服务的配置文件 application.yml，加入 Eureka 配置 如下： eureka:client:registerWithEureka: true 服务注册开关fetchRegistry: true 服务发现开关serviceUrl: Eureka客户端与Eureka服务端进行交互的地址，多个中间用逗号分隔defaultZone: ${EUREKA_SERVER:http://localhost:50101/eureka/,http://localhost:50102/eureka/}instance:prefer-ip-address: true 将自己的ip地址注册到Eureka服务中ip-address: ${IP_ADDRESS:127.0.0.1}instance-id: ${spring.application.name}:${server.port} 指定实例idribbon:MaxAutoRetries: 2 最大重试次数，当Eureka中可以找到服务，但是服务连不上时将会重试，如果eureka中找不到服务则直接走断路器MaxAutoRetriesNextServer: 3 切换实例的重试次数OkToRetryOnAllOperations: false 对所有操作请求都进行重试，如果是get则可以，如果是post，put等操作没有实现幂等的情况下是很危险的,所以设置为falseConnectTimeout: 5000 请求连接的超时时间ReadTimeout: 6000 请求处理的超时时间 3、添加 eureka 依赖 <dependency><groupId>org.springframework.cloud</groupId><artifactId>spring‐cloud‐starter‐netflix‐eureka‐client</artifactId></dependency> 4、修改启动类，在class上添加如下注解： @EnableDiscoveryClient 搜索服务客户端 在 学习服务 创建搜索服务的客户端接口，此接口会生成代理对象，调用搜索服务： package com.xuecheng.learning.client;import com.xuecheng.framework.domain.course.TeachplanMediaPub;import org.springframework.cloud.openfeign.FeignClient;import org.springframework.web.bind.annotation.GetMapping;import org.springframework.web.bind.annotation.PathVariable;@FeignClient(value = "xc‐service‐search")public interface CourseSearchClient {@GetMapping(value="/getmedia/{teachplanId}")public TeachplanMediaPub getmedia(@PathVariable("teachplanId") String teachplanId);} 自定义错误代码 我们在 com.xuecheng.framework.domain.learning.response 包下自定义一个错误消息模型 package com.xuecheng.framework.domain.learning.response;import com.xuecheng.framework.model.response.ResultCode;import lombok.ToString;@ToStringpublic enum LearningCode implements ResultCode {LEARNING_GET_MEDIA_ERROR(false,23001,"学习中心获取媒资信息错误！");//操作代码boolean success;//操作代码int code;//提示信息String message;private LearningCode(boolean success, int code, String message){this.success = success;this.code = code;this.message = message;}@Overridepublic boolean success() {return success;}@Overridepublic int code() {return code;}@Overridepublic String message() {return message;} } 该消息模型基于 ResultCode 来实现，代码如下 package com.xuecheng.framework.model.response;/ Created by mrt on 2018/3/5. 10000-- 通用错误代码 22000-- 媒资错误代码 23000-- 用户中心错误代码 24000-- cms错误代码 25000-- 文件系统/public interface ResultCode {//操作是否成功,true为成功，false操作失败boolean success();//操作代码int code();//提示信息String message(); 从 ResultCode 中我们可以看出，我们约定了用户中心的错误代码使用 23000，所以我们定义的一些错误信息的代码就从 23000 开始计数。 Service 在学习服务中定义 service 方法，此方法远程请求课程管理服务、媒资管理服务获取课程学习地址。 package com.xuecheng.learning.service.impl;import com.netflix.discovery.converters.Auto;import com.xuecheng.framework.domain.course.TeachplanMediaPub;import com.xuecheng.framework.domain.learning.response.GetMediaResult;import com.xuecheng.framework.exception.ExceptionCast;import com.xuecheng.framework.model.response.CommonCode;import com.xuecheng.learning.client.CourseSearchClient;import com.xuecheng.learning.service.LearningService;import org.springframework.beans.factory.annotation.Autowired;import org.springframework.stereotype.Service;@Servicepublic class LearningServiceImpl implements LearningService {@AutowiredCourseSearchClient courseSearchClient;/ 远程调用搜索服务获取已发布媒体信息中的url @param courseId 课程id @param teachplanId 媒体信息id @return/@Overridepublic GetMediaResult getMediaPlayUrl(String courseId, String teachplanId) {//校验学生权限,是否已付费等//远程调用搜索服务进行查询媒体信息TeachplanMediaPub mediaPub = courseSearchClient.getmedia(teachplanId);if(mediaPub == null) ExceptionCast.cast(CommonCode.FAIL);return new GetMediaResult(CommonCode.SUCCESS, mediaPub.getMediaUrl());} } Controller 调用 service 根据课程计划 id 查询视频播放地址： @RestController@RequestMapping("/learning/course")public class CourseLearningController implements CourseLearningControllerApi {@AutowiredLearningService learningService;@Override@GetMapping("/getmedia/{courseId}/{teachplanId}")public GetMediaResult getMediaPlayUrl(@PathVariable String courseId, @PathVariable String teachplanId) {//获取课程学习地址return learningService.getMedia(courseId, teachplanId);} } 测试 使用 swagger-ui 或postman 测试学习服务查询课程视频地址接口。 0x05 前端开发 需求分析 需要在学习中心前端页面需要完成如下功能： 1、进入课程学习页面需要带上 课程 Id参数及课程计划Id的参数，其中 课程 Id 参数必带，课程计划 Id 可以为空。 2、进入页面根据 课程 Id 取出该课程的课程计划显示在右侧。 3、进入页面后判断如果请求参数中有课程计划 Id 则播放该章节的视频。 4、进入页面后判断如果 课程计划id 为0则需要取出本课程第一个 课程计划的Id，并播放第一个课程计划的视频。 进入到模块 xc-ui-pc-leanring/src/module/course api方法 let sysConfig = require('@/../config/sysConfig')let apiUrl = sysConfig.xcApiUrlPre;/获取播放地址/export const get_media = (courseId,chapter) => {return http.requestGet(apiUrl+'/api/learning/course/getmedia/'+courseId+'/'+chapter);} 配置代理 在 Nginx 中的 ucenter.xuecheng.com 虚拟主机中配置 /api/learning/ 的路径转发，此url 请转发到学习服务。 学习服务upstream learning_server_pool{server 127.0.0.1:40600 weight=10;}学成网用户中心server {listen 80;server_name ucenter.xuecheng.com;个人中心location / {proxy_pass http://ucenter_server_pool;}后端搜索服务location /openapi/search/ {proxy_pass http://search_server_pool/search/; }学习服务location ^~ /api/learning/ {proxy_pass http://learning_server_pool/learning/;} } 视频播放页面 1、如果传入的课程计划id为0则取出第一个课程计划id 在 created 钩子方法中完成 created(){//当前请求的urlthis.url = window.location//课程idthis.courseId = this.$route.params.courseId//章节idthis.chapter = this.$route.params.chapter//查询课程信息systemApi.course_view(this.courseId).then((view_course)=>{if(!view_course || !view_course[this.courseId]){this.$message.error("获取课程信息失败，请重新进入此页面！")return ;}let courseInfo = view_course[this.courseId]console.log(courseInfo)this.coursename = courseInfo.nameif(courseInfo.teachplan){console.log("准备开始播放视频")let teachplan = JSON.parse(courseInfo.teachplan);this.teachplanList = teachplan.children;//开始学习if(this.chapter == "0" || !this.chapter){//取出第一个教学计划this.chapter = this.getFirstTeachplan();console.log("第一个教学计划id为 ",this.chapter);this.study(this.chapter);}else{this.study(this.chapter);} }})}, 取出第一个章节 id，用户未输入课程计划 id 或者输入为 0 时，播放第一个。 //取出第一个章节getFirstTeachplan(){for(var i=0;i<this.teachplanList.length;i++){let firstTeachplan = this.teachplanList[i];//如果当前children存在，则取出第一个返回if(firstTeachplan.children && firstTeachplan.children.length>0){let secondTeachplan = firstTeachplan.children[0];return secondTeachplan.id;} }return ;}, 开始学习： //开始学习study(chapter){// 获取播放地址courseApi.get_media(this.courseId,chapter).then((res)=>{if(res.success){let fileUrl = sysConfig.videoUrl + res.fileUrl//播放视频this.playvideo(fileUrl)}else if(res.message){this.$message.error(res.message)}else{this.$message.error("播放视频失败，请刷新页面重试")} }).catch(res=>{this.$message.error("播放视频失败，请刷新页面重试")});}, 2、点击右侧课程章节切换播放 在原有代码基础上添加 click 事件，点击调用开始学习方法（study）。 <li v‐if="teachplan_first.children!=null" v‐for="(teachplan_second, index) inteachplan_first.children"><i class="glyphicon glyphicon‐check"></i><a :href="url" @click="study(teachplan_second.id)">{ {teachplan_second.pname} }</a></li> 3、地址栏路由url变更 这里需要注意一个问题，在用户点击课程章节切换播放时，地址栏的 url 也应该同步改变为当前所选择的课程计划 id 4、在线学习按钮 将 learnstatus 默认更改为 1，这样就能显示出马上学习的按钮，方便我们后续的集成测试。 文件路径为 xc-ui-pc-static-portal/include/course_detail_dynamic.html 部分代码块如下 <script>var body= new Vue({ //创建一个Vue的实例el: "body", //挂载点是id="app"的地方data: {editLoading: false,title:'测试',courseId:'',charge:'',//203001免费,203002收费learnstatus: 1 ,//课程状态，1：马上学习，2：立即报名、3：立即购买course:{},companyId:'template',company_stat:[],course_stat:{"s601001":"","s601002":"","s601003":""} }, 简单的测试 访问在线学习页面：http://ucenter.xuecheng.com//learning/课程id/课程计划id 通过 url 传入两个参数：课程id 和 课程计划id 如果没有课程计划则传入0 测试项目如下： 1、传入正确的课程id、课程计划id，自动播放本章节的视频 2、传入正确的课程id、课程计划id传入0，自动播放第一个视频 3、传入错误的课程id 或 课程计划id，提示错误信息。 4、通过右侧章节目录切换章节及播放视频。 访问： http://ucenter.xuecheng.com//learning/4028e58161bcf7f40161bcf8b77c0000/4028e58161bd18ea0161bd1f73190008 传入正确的课程id、课程计划id，自动播放本章节的视频 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Ef0xxym7-1595567273153)(https://qnoss.codeyee.com/20200704_15/image17)] 传入正确的课程id、课程计划id传入0，自动播放第一个视频 访问 http://ucenter.xuecheng.com//learning/4028e58161bcf7f40161bcf8b77c0000/0 识别出第一个课程计划的 id 需要注意的是这里的 chapter 参数是我自己在 study 函数里加上去的，可以忽略。 传入错误的课程id或课程计划id，提示错误信息。 通过右侧章节目录切换章节及播放视频。 点击章节即可播放，但是点击制定章节后 url 没有发生改变，这个问题暂时还没有解决，关注笔记后面的内容。 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-TOGdxwb4-1595567273158)(https://qnoss.codeyee.com/20200704_15/image20)] 完整的测试 准备工作 启动 RabbitMQ，启动 Logstash、ElasticSearch 建议把所有后端服务都开起来 启动 前端静态门户、启动 nginx 、启动课程管理前端 我们整理一下测试的流程 上传两个媒资视频文件，用于测试 进入到课程管理，为课程计划选择媒资信息 发布课程，等待 logstash 将数据采集到 ElasticSearch 的索引库中 进入学成网主页，点击课程，进入到搜索门户页面 搜索课程，进入到课程详情页面 点击开始学习，进入到课程学习页面，选择课程计划中的一个章节进行学习。 1、上传文件 首先我们使用之前开发的媒资管理模块，上传两个视频文件用于测试。 第一个文件上传成功 一些问题 在上传第二个文件时，发生了错误，我们来检查一下问题出在了哪里 在媒体服务的控制台中可以看到，在 mergeChunks 方法在校验文件 md5 时候抛出了异常 我们在 MD5 校验这里打个断点，重新上传文件，分析一下问题所在。 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-OpEMZGI8-1595567273166)(https://qnoss.codeyee.com/20200704_15/image23)] 单步调试后发现，合并文件后的MD5值与用户上传的源文件值不相等 方案1：删除本地分块文件重新尝试上传 考虑到可能是在用户上传完 视频的分块文件时发生了一些问题，导致合并文件后与源文件的大小不等，导致MD5也不相同，这里我们把这个视频上传到本地的文件全部删除，在媒资上传页面重新上传文件。 对比所有分块文件的字节大小和本地源文件的大小，完全是相等的 删除所有文件后重新上传，md5值还是不等，考虑从调试一下文件合并的代码。 方案2：检查前端提交的MD5值是否正确 在查阅是否有其他的MD5值获取方案时，发现了一个使用 windows 本地命令获取文件MD5值的方法 certutil -hashfile .\19-在线学习接口-集成测试.avi md5 惊奇的发现，TM的原来是前端那边转换的MD5值不正确，后端这边是没有问题的。 从前面的图可以看出，本地和后端转换的都是以一个 f6f0 开头的MD5值 那么问题就出现在前端了，还需要花一些时间去分析一下，这里暂时就先告一段落，因为上传了几个文件测试中只有这一个文件出现了问题。 2、为课程计划选择媒资信息 进入到一个课程的管理页面 http://localhost:12000//course/manage/baseinfo/4028e58161bcf7f40161bcf8b77c0000 将刚才我们上传的媒资文件的信息和课程计划绑定 选择效果如下 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-epKaqzCD-1595567273178)(https://qnoss.codeyee.com/20200704_15/image29)] 2、发布课程，等待 logstash 从 course_pub 以及 teachplan_media_pub 表中采集数据到 ElasticSearch 当中 发布成功后，我们可以从 teachplan_media_pub 表中看到刚才我们发布的媒资信息 再观察 Logstash 的控制台，发现两个 Logstash 的实例都对更新的课程发布信息进行了采集 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hTUve2ik-1595567273183)(https://qnoss.codeyee.com/20200704_15/image32)] 3、前端门户测试 打开我们的门户主站 http://www.xuecheng.com/ [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4wZe9R84-1595567273185)(https://qnoss.codeyee.com/20200704_15/image33)] 点击导航栏的课程，进入到我们的搜索门户页面 如果无法进入到搜索门户，请检查你的 xc-ui-pc-portal 前端工程是否已经启动 进入到搜索门户后，可以看到一些初始化时搜索的课程数据，默认是搜索第一页的数据，每页2个课程。 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BJ1AKoJb-1595567273187)(https://qnoss.codeyee.com/20200704_15/image34)] 我们可以测试搜索一下前面我们选择媒资信息时所用的课程 点击课程，进入到课程详情页面，然后再点击开始学习。 点击马上学习后，会进入到该课程的在线学习页面，默认自动播放我们第一个课程计划中的视频。 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-tcuLWnf2-1595567273193)(https://qnoss.codeyee.com/20200704_15/image37)] 我们可以在右侧的目录中选择第二个课程计划，会自动播放所选的课程计划所对应的媒资视频播放地址，该 播放地址正是我们刚才通过 Logstash 自动采集到 ElasticSearch 的索引信息，效果图如下 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Cvi9Dr0Y-1595567273195)(https://qnoss.codeyee.com/20200704_15/image38)] 四、待完善的一些功能 课程发布前，校验课程计划里面是否包含二级课程计划 课程发布前，校验课程计划信息里面是否全部包含媒资信息 删除媒资信息，并且同步删除ES中的索引 在获取该课程的播放地址时校验用户的合法、 在线学习页面，点击右侧目录中的课程计划同时改变url中的课程计划地址 视频文件 19-在线学习接口-集成测试.avi 前端上传时提交的MD5值不正确 😁 认识作者 作者：👦 LCyee ，全干型代码🐕 自建博客：https://www.codeyee.com 记录学习以及项目开发过程中的笔记与心得，记录认知迭代的过程，分享想法与观点。 CSDN 博客：https://blog.csdn.net/codeyee 记录和分享一些开发过程中遇到的问题以及解决的思路。 欢迎加入微服务练习生的队伍，一起交流项目学习过程中的一些问题、分享学习心得等，不定期组织一起刷题、刷项目，共同见证成长。 本篇文章为转载内容。原文链接：https://blog.csdn.net/codeyee/article/details/107558901。 该文由互联网用户投稿提供，文中观点代表作者本人意见，并不代表本站的立场。 作为信息平台，本站仅提供文章转载服务，并不拥有其所有权，也不对文章内容的真实性、准确性和合法性承担责任。 如发现本文存在侵权、违法、违规或事实不符的情况，请及时联系我们，我们将第一时间进行核实并删除相应内容。

...直接渲染。 尽量不要使用 eval, new Function()，document.write()，document.writeln()，window.setInterval()，window.setTimeout()，innerHTML，document.creteElement() 等可执行字符串的方法。 如果做不到以上几点，也必须对涉及 DOM 渲染的方法传入的字符串参数做 escape 转义。 前端渲染的时候对任何的字段都需要做 escape 转义编码。 escape 转义的目的是将一些构成 HTML 标签的元素转义，比如 <，>，空格 等，转义成 <，>， 等显示转义字符。有很多开源的工具可以协助我们做 escape 转义。 持久型 XSS 持久型 XSS 漏洞，也被称为存储型 XSS 漏洞，一般存在于 Form 表单提交等交互功能，如发帖留言，提交文本信息等，黑客利用的 XSS 漏洞，将内容经正常功能提交进入数据库持久保存，当前端页面获得后端从数据库中读出的注入代码时，恰好将其渲染执行。 主要注入页面方式和非持久型 XSS 漏洞类似，只不过持久型的不是来源于 URL，refferer，forms 等，而是来源于后端从数据库中读出来的数据。持久型 XSS 攻击不需要诱骗点击，黑客只需要在提交表单的地方完成注入即可，但是这种 XSS 攻击的成本相对还是很高。攻击成功需要同时满足以下几个条件： POST 请求提交表单后端没做转义直接入库。 后端从数据库中取出数据没做转义直接输出给前端。 前端拿到后端数据没做转义直接渲染成 DOM。 持久型 XSS 有以下几个特点： 持久性，植入在数据库中 危害面广，甚至可以让用户机器变成 DDoS 攻击的肉鸡。 盗取用户敏感私密信息 为了防止持久型 XSS 漏洞，需要前后端共同努力： 后端在入库前应该选择不相信任何前端数据，将所有的字段统一进行转义处理。 后端在输出给前端数据统一进行转义处理。 前端在渲染页面 DOM 的时候应该选择不相信任何后端数据，任何字段都需要做转义处理。 基于字符集的 XSS 其实现在很多的浏览器以及各种开源的库都专门针对了 XSS 进行转义处理，尽量默认抵御绝大多数 XSS 攻击，但是还是有很多方式可以绕过转义规则，让人防不胜防。比如「基于字符集的 XSS 攻击」就是绕过这些转义处理的一种攻击方式，比如有些 Web 页面字符集不固定，用户输入非期望字符集的字符，有时会绕过转义过滤规则。 以基于 utf-7 的 XSS 为例 utf-7 是可以将所有的 unicode 通过 7bit 来表示的一种字符集 (但现在已经从 Unicode 规格中移除)。 这个字符集为了通过 7bit 来表示所有的文字, 除去数字和一部分的符号,其它的部分将都以 base64 编码为基础的方式呈现。 <script>alert("xss")</script>可以被解释为：+ADw-script+AD4-alert(+ACI-xss+ACI-)+ADw-/script+AD4- 可以形成「基于字符集的 XSS 攻击」的原因是由于浏览器在 meta 没有指定 charset 的时候有自动识别编码的机制，所以这类攻击通常就是发生在没有指定或者没来得及指定 meta 标签的 charset 的情况下。 所以我们有什么办法避免这种 XSS 呢？ 记住指定 XML 中不仅要指定字符集为 utf-8，而且标签要闭合 牛文推荐：http://drops.wooyun.org/papers/1327 （这个讲的很详细） 基于 Flash 的跨站 XSS 基于 Flash 的跨站 XSS 也是属于反射型 XSS 的一种，虽然现在开发 ActionScript 的产品线几乎没有了，但还是提一句吧，AS 脚本可以接受用户输入并操作 cookie，攻击者可以配合其他 XSS（持久型或者非持久型）方法将恶意 swf 文件嵌入页面中。主要是因为 AS 有时候需要和 JS 传参交互，攻击者会通过恶意的 XSS 注入篡改参数，窃取并操作cookie。 避免方法： 严格管理 cookie 的读写权限 对 Flash 能接受用户输入的参数进行过滤 escape 转义处理 未经验证的跳转 XSS 有一些场景是后端需要对一个传进来的待跳转的 URL 参数进行一个 302 跳转，可能其中会带有一些用户的敏感（cookie）信息。如果服务器端做302 跳转，跳转的地址来自用户的输入，攻击者可以输入一个恶意的跳转地址来执行脚本。 这时候需要通过以下方式来防止这类漏洞： 对待跳转的 URL 参数做白名单或者某种规则过滤 后端注意对敏感信息的保护, 比如 cookie 使用来源验证。 CSRF CSRF（Cross-Site Request Forgery），中文名称：跨站请求伪造攻击 那么 CSRF 到底能够干嘛呢？你可以这样简单的理解：攻击者可以盗用你的登陆信息，以你的身份模拟发送各种请求。攻击者只要借助少许的社会工程学的诡计，例如通过 QQ 等聊天软件发送的链接(有些还伪装成短域名，用户无法分辨)，攻击者就能迫使 Web 应用的用户去执行攻击者预设的操作。例如，当用户登录网络银行去查看其存款余额，在他没有退出时，就点击了一个 QQ 好友发来的链接，那么该用户银行帐户中的资金就有可能被转移到攻击者指定的帐户中。 所以遇到 CSRF 攻击时，将对终端用户的数据和操作指令构成严重的威胁。当受攻击的终端用户具有管理员帐户的时候，CSRF 攻击将危及整个 Web 应用程序。 CSRF 原理 下图大概描述了 CSRF 攻击的原理，可以理解为有一个小偷在你配钥匙的地方得到了你家的钥匙，然后拿着要是去你家想偷什么偷什么。 csrf原理 完成 CSRF 攻击必须要有三个条件： 用户已经登录了站点 A，并在本地记录了 cookie 在用户没有登出站点 A 的情况下（也就是 cookie 生效的情况下），访问了恶意攻击者提供的引诱危险站点 B (B 站点要求访问站点A)。 站点 A 没有做任何 CSRF 防御 你也许会问：「如果我不满足以上三个条件中的任意一个，就不会受到 CSRF 的攻击」。其实可以这么说的，但你不能保证以下情况不会发生： 你不能保证你登录了一个网站后，不再打开一个 tab 页面并访问另外的网站，特别现在浏览器都是支持多 tab 的。 你不能保证你关闭浏览器了后，你本地的 cookie 立刻过期，你上次的会话已经结束。 上图中所谓的攻击网站 B，可能是一个存在其他漏洞的可信任的经常被人访问的网站。 预防 CSRF CSRF 的防御可以从服务端和客户端两方面着手，防御效果是从服务端着手效果比较好，现在一般的 CSRF 防御也都在服务端进行。服务端的预防 CSRF 攻击的方式方法有多种，但思路上都是差不多的，主要从以下两个方面入手： 正确使用 GET，POST 请求和 cookie 在非 GET 请求中增加 token 一般而言，普通的 Web 应用都是以 GET、POST 请求为主，还有一种请求是 cookie 方式。我们一般都是按照如下规则设计应用的请求： GET 请求常用在查看，列举，展示等不需要改变资源属性的时候（数据库 query 查询的时候） POST 请求常用在 From 表单提交，改变一个资源的属性或者做其他一些事情的时候（数据库有 insert、update、delete 的时候） 当正确的使用了 GET 和 POST 请求之后，剩下的就是在非 GET 方式的请求中增加随机数，这个大概有三种方式来进行： 为每个用户生成一个唯一的 cookie token，所有表单都包含同一个伪随机值，这种方案最简单，因为攻击者不能获得第三方的 cookie(理论上)，所以表单中的数据也就构造失败，但是由于用户的 cookie 很容易由于网站的 XSS 漏洞而被盗取，所以这个方案必须要在没有 XSS 的情况下才安全。 每个 POST 请求使用验证码，这个方案算是比较完美的，但是需要用户多次输入验证码，用户体验比较差，所以不适合在业务中大量运用。 渲染表单的时候，为每一个表单包含一个 csrfToken，提交表单的时候，带上 csrfToken，然后在后端做 csrfToken 验证。 CSRF 的防御可以根据应用场景的不同自行选择。CSRF 的防御工作确实会在正常业务逻辑的基础上带来很多额外的开发量，但是这种工作量是值得的，毕竟用户隐私以及财产安全是产品最基础的根本。 SQL 注入 SQL 注入漏洞（SQL Injection）是 Web 开发中最常见的一种安全漏洞。可以用它来从数据库获取敏感信息，或者利用数据库的特性执行添加用户，导出文件等一系列恶意操作，甚至有可能获取数据库乃至系统用户最高权限。 而造成 SQL 注入的原因是因为程序没有有效的转义过滤用户的输入，使攻击者成功的向服务器提交恶意的 SQL 查询代码，程序在接收后错误的将攻击者的输入作为查询语句的一部分执行，导致原始的查询逻辑被改变，额外的执行了攻击者精心构造的恶意代码。 很多 Web 开发者没有意识到 SQL 查询是可以被篡改的，从而把 SQL 查询当作可信任的命令。殊不知，SQL 查询是可以绕开访问控制，从而绕过身份验证和权限检查的。更有甚者，有可能通过 SQL 查询去运行主机系统级的命令。 SQL 注入原理 下面将通过一些真实的例子来详细讲解 SQL 注入的方式的原理。 考虑以下简单的管理员登录表单： <form action="/login" method="POST"><p>Username: <input type="text" name="username" /></p><p>Password: <input type="password" name="password" /></p><p><input type="submit" value="登陆" /></p></form> 后端的 SQL 语句可能是如下这样的： let querySQL = SELECT FROM userWHERE username='${username}'AND psw='${password}'; // 接下来就是执行 sql 语句… 目的就是来验证用户名和密码是不是正确，按理说乍一看上面的 SQL 语句也没什么毛病，确实是能够达到我们的目的，可是你只是站在用户会老老实实按照你的设计来输入的角度来看问题，如果有一个恶意攻击者输入的用户名是 zoumiaojiang’ OR 1 = 1 --，密码随意输入，就可以直接登入系统了。WFT! 冷静下来思考一下，我们之前预想的真实 SQL 语句是: SELECT FROM user WHERE username='zoumiaojiang' AND psw='mypassword' 可以恶意攻击者的奇怪用户名将你的 SQL 语句变成了如下形式： SELECT FROM user WHERE username='zoumiaojiang' OR 1 = 1 --' AND psw='xxxx' 在 SQL 中，-- 是注释后面的内容的意思，所以查询语句就变成了： SELECT FROM user WHERE username='zoumiaojiang' OR 1 = 1 这条 SQL 语句的查询条件永远为真，所以意思就是恶意攻击者不用我的密码，就可以登录进我的账号，然后可以在里面为所欲为，然而这还只是最简单的注入，牛逼的 SQL 注入高手甚至可以通过 SQL 查询去运行主机系统级的命令，将你主机里的内容一览无余，这里我也没有这个能力讲解的太深入，毕竟不是专业研究这类攻击的，但是通过以上的例子，已经了解了 SQL 注入的原理，我们基本已经能找到防御 SQL 注入的方案了。 如何预防 SQL 注入 防止 SQL 注入主要是不能允许用户输入的内容影响正常的 SQL 语句的逻辑，当用户的输入的信息将要用来拼接 SQL 语句的话，我们应该永远选择不相信，任何内容都必须进行转义过滤，当然做到这个还是不够的，下面列出防御 SQL 注入的几点注意事项： 严格限制Web应用的数据库的操作权限，给此用户提供仅仅能够满足其工作的最低权限，从而最大限度的减少注入攻击对数据库的危害 后端代码检查输入的数据是否符合预期，严格限制变量的类型，例如使用正则表达式进行一些匹配处理。 对进入数据库的特殊字符（’，"，\，<，>，&，，; 等）进行转义处理，或编码转换。基本上所有的后端语言都有对字符串进行转义处理的方法，比如 lodash 的 lodash._escapehtmlchar 库。 所有的查询语句建议使用数据库提供的参数化查询接口，参数化的语句使用参数而不是将用户输入变量嵌入到 SQL 语句中，即不要直接拼接 SQL 语句。例如 Node.js 中的 mysqljs 库的 query 方法中的 ? 占位参数。 mysql.query(SELECT FROM user WHERE username = ? AND psw = ?, [username, psw]); 在应用发布之前建议使用专业的 SQL 注入检测工具进行检测，以及时修补被发现的 SQL 注入漏洞。网上有很多这方面的开源工具，例如 sqlmap、SQLninja 等。 避免网站打印出 SQL 错误信息，比如类型错误、字段不匹配等，把代码里的 SQL 语句暴露出来，以防止攻击者利用这些错误信息进行 SQL 注入。 不要过于细化返回的错误信息，如果目的是方便调试，就去使用后端日志，不要在接口上过多的暴露出错信息，毕竟真正的用户不关心太多的技术细节，只要话术合理就行。 碰到要操作的数据库的代码，一定要慎重，小心使得万年船，多找几个人多来几次 code review，将问题都暴露出来，而且要善于利用工具，操作数据库相关的代码属于机密，没事不要去各种论坛晒自家站点的 SQL 语句，万一被人盯上了呢？ 命令行注入 命令行注入漏洞，指的是攻击者能够通过 HTTP 请求直接侵入主机，执行攻击者预设的 shell 命令，听起来好像匪夷所思，这往往是 Web 开发者最容易忽视但是却是最危险的一个漏洞之一，看一个实例： 假如现在需要实现一个需求：用户提交一些内容到服务器，然后在服务器执行一些系统命令去产出一个结果返回给用户，接口的部分实现如下： // 以 Node.js 为例，假如在接口中需要从 github 下载用户指定的 repoconst exec = require('mz/child_process').exec;let params = {/ 用户输入的参数 /};exec(git clone ${params.repo} /some/path); 这段代码确实能够满足业务需求，正常的用户也确实能从指定的 git repo 上下载到想要的代码，可是和 SQL 注入一样，这段代码在恶意攻击者眼中，简直就是香饽饽。 如果 params.repo 传入的是 https://github.com/zoumiaojiang/zoumiaojiang.github.io.git 当然没问题了。 可是如果 params.repo 传入的是 https://github.com/xx/xx.git && rm -rf / && 恰好你的服务是用 root 权限起的就惨了。 具体恶意攻击者能用命令行注入干什么也像 SQL 注入一样，手法是千变万化的，比如「反弹 shell 注入」等，但原理都是一样的，我们绝对有能力防止命令行注入发生。防止命令行注入需要做到以下几件事情： 后端对前端提交内容需要完全选择不相信，并且对其进行规则限制（比如正则表达式）。 在调用系统命令前对所有传入参数进行命令行参数转义过滤。 不要直接拼接命令语句，借助一些工具做拼接、转义预处理，例如 Node.js 的 shell-escape npm 包。 还是前面的例子，我们可以做到如下： const exec = require('mz/child_process').exec;// 借助 shell-escape npm 包解决参数转义过滤问题const shellescape = require('shell-escape');let params = {/ 用户输入的参数 /};// 先过滤一下参数，让参数符合预期if (!/正确的表达式/.test(params.repo)) {return;}let cmd = shellescape(['git','clone',params.repo,'/some/path']);// cmd 的值: git clone 'https://github.com/xx/xx.git && rm -rf / &&' /some/path// 这样就不会被注入成功了。exec(cmd); DDoS 攻击 DDoS 又叫分布式拒绝服务，全称 Distributed Denial of Service，其原理就是利用大量的请求造成资源过载，导致服务不可用，这个攻击应该不能算是安全问题，这应该算是一个另类的存在，因为这种攻击根本就是耍流氓的存在，「伤敌一千，自损八百」的行为。出于保护 Web App 不受攻击的攻防角度，还是介绍一下 DDoS 攻击吧，毕竟也是挺常见的。 DDoS 攻击可以理解为：「你开了一家店，隔壁家点看不惯，就雇了一大堆黑社会人员进你店里干坐着，也不消费，其他客人也进不来，导致你营业惨淡」。为啥说 DDoS 是个「伤敌一千，自损八百」的行为呢？毕竟隔壁店还是花了不少钱雇黑社会但是啥也没得到不是？DDoS 攻击的目的基本上就以下几个： 深仇大恨，就是要干死你 敲诈你，不给钱就干你 忽悠你，不买我防火墙服务就会有“人”继续干你 也许你的站点遭受过 DDoS 攻击，具体什么原因怎么解读见仁见智。DDos 攻击从层次上可分为网络层攻击与应用层攻击，从攻击手法上可分为快型流量攻击与慢型流量攻击，但其原理都是造成资源过载，导致服务不可用。 网络层 DDoS 网络层 DDos 攻击包括 SYN Flood、ACK Flood、UDP Flood、ICMP Flood 等。 SYN Flood 攻击 SYN flood 攻击主要利用了 TCP 三次握手过程中的 Bug，我们都知道 TCP 三次握手过程是要建立连接的双方发送 SYN，SYN + ACK，ACK 数据包，而当攻击方随意构造源 IP 去发送 SYN 包时，服务器返回的 SYN + ACK 就不能得到应答（因为 IP 是随意构造的），此时服务器就会尝试重新发送，并且会有至少 30s 的等待时间，导致资源饱和服务不可用，此攻击属于慢型 DDoS 攻击。 ACK Flood 攻击 ACK Flood 攻击是在 TCP 连接建立之后，所有的数据传输 TCP 报文都是带有 ACK 标志位的，主机在接收到一个带有 ACK 标志位的数据包的时候，需要检查该数据包所表示的连接四元组是否存在，如果存在则检查该数据包所表示的状态是否合法，然后再向应用层传递该数据包。如果在检查中发现该数据包不合法，例如该数据包所指向的目的端口在本机并未开放，则主机操作系统协议栈会回应 RST 包告诉对方此端口不存在。 UDP Flood 攻击 UDP flood 攻击是由于 UDP 是一种无连接的协议，因此攻击者可以伪造大量的源 IP 地址去发送 UDP 包，此种攻击属于大流量攻击。正常应用情况下，UDP 包双向流量会基本相等，因此发起这种攻击的攻击者在消耗对方资源的时候也在消耗自己的资源。 ICMP Flood 攻击 ICMP Flood 攻击属于大流量攻击，其原理就是不断发送不正常的 ICMP 包（所谓不正常就是 ICMP 包内容很大），导致目标带宽被占用，但其本身资源也会被消耗。目前很多服务器都是禁 ping 的（在防火墙在可以屏蔽 ICMP 包），因此这种攻击方式已经落伍。 网络层 DDoS 防御 网络层的 DDoS 攻击究其本质其实是无法防御的，我们能做得就是不断优化服务本身部署的网络架构，以及提升网络带宽。当然，还是做好以下几件事也是有助于缓解网络层 DDoS 攻击的冲击： 网络架构上做好优化，采用负载均衡分流。 确保服务器的系统文件是最新的版本，并及时更新系统补丁。 添加抗 DDos 设备，进行流量清洗。 限制同时打开的 SYN 半连接数目，缩短 SYN 半连接的 Timeout 时间。 限制单 IP 请求频率。 防火墙等防护设置禁止 ICMP 包等。 严格限制对外开放的服务器的向外访问。 运行端口映射程序或端口扫描程序，要认真检查特权端口和非特权端口。 关闭不必要的服务。 认真检查网络设备和主机/服务器系统的日志。只要日志出现漏洞或是时间变更,那这台机器就可能遭到了攻击。 限制在防火墙外与网络文件共享。这样会给黑客截取系统文件的机会，主机的信息暴露给黑客，无疑是给了对方入侵的机会。 加钱堆机器。。 报警。。 应用层 DDoS 应用层 DDoS 攻击不是发生在网络层，是发生在 TCP 建立握手成功之后，应用程序处理请求的时候，现在很多常见的 DDoS 攻击都是应用层攻击。应用层攻击千变万化，目的就是在网络应用层耗尽你的带宽，下面列出集中典型的攻击类型。 CC 攻击 当时绿盟为了防御 DDoS 攻击研发了一款叫做 Collapasar 的产品，能够有效的防御 SYN Flood 攻击。黑客为了挑衅，研发了一款 Challenge Collapasar 攻击工具（简称 CC）。 CC 攻击的原理，就是针对消耗资源比较大的页面不断发起不正常的请求，导致资源耗尽。因此在发送 CC 攻击前，我们需要寻找加载比较慢，消耗资源比较多的网页，比如需要查询数据库的页面、读写硬盘文件的等。通过 CC 攻击，使用爬虫对某些加载需要消耗大量资源的页面发起 HTTP 请求。 DNS Flood DNS Flood 攻击采用的方法是向被攻击的服务器发送大量的域名解析请求，通常请求解析的域名是随机生成或者是网络世界上根本不存在的域名，被攻击的DNS 服务器在接收到域名解析请求的时候首先会在服务器上查找是否有对应的缓存，如果查找不到并且该域名无法直接由服务器解析的时候，DNS 服务器会向其上层 DNS 服务器递归查询域名信息。域名解析的过程给服务器带来了很大的负载，每秒钟域名解析请求超过一定的数量就会造成 DNS 服务器解析域名超时。 根据微软的统计数据，一台 DNS 服务器所能承受的动态域名查询的上限是每秒钟 9000 个请求。而我们知道，在一台 P3 的 PC 机上可以轻易地构造出每秒钟几万个域名解析请求，足以使一台硬件配置极高的 DNS 服务器瘫痪，由此可见 DNS 服务器的脆弱性。 HTTP 慢速连接攻击 针对 HTTP 协议，先建立起 HTTP 连接，设置一个较大的 Conetnt-Length，每次只发送很少的字节，让服务器一直以为 HTTP 头部没有传输完成，这样连接一多就很快会出现连接耗尽。 应用层 DDoS 防御 判断 User-Agent 字段（不可靠，因为可以随意构造） 针对 IP + cookie，限制访问频率（由于 cookie 可以更改，IP 可以使用代理，或者肉鸡，也不可靠) 关闭服务器最大连接数等，合理配置中间件，缓解 DDoS 攻击。 请求中添加验证码，比如请求中有数据库操作的时候。 编写代码时，尽量实现优化，并合理使用缓存技术，减少数据库的读取操作。 加钱堆机器。。 报警。。 应用层的防御有时比网络层的更难，因为导致应用层被 DDoS 攻击的因素非常多，有时往往是因为程序员的失误，导致某个页面加载需要消耗大量资源，有时是因为中间件配置不当等等。而应用层 DDoS 防御的核心就是区分人与机器（爬虫），因为大量的请求不可能是人为的，肯定是机器构造的。因此如果能有效的区分人与爬虫行为，则可以很好地防御此攻击。 其他 DDoS 攻击 发起 DDoS 也是需要大量的带宽资源的，但是互联网就像森林，林子大了什么鸟都有，DDoS 攻击者也能找到其他的方式发起廉价并且极具杀伤力的 DDoS 攻击。 利用 XSS 举个例子，如果 12306 页面有一个 XSS 持久型漏洞被恶意攻击者发现，只需在春节抢票期间在这个漏洞中执行脚本使得往某一个小站点随便发点什么请求，然后随着用户访问的增多，感染用户增多，被攻击的站点自然就会迅速瘫痪了。这种 DDoS 简直就是无本万利，不用惊讶，现在大站有 XSS 漏洞的不要太多。 来自 P2P 网络攻击 大家都知道，互联网上的 P2P 用户和流量都是一个极为庞大的数字。如果他们都去一个指定的地方下载数据，成千上万的真实 IP 地址连接过来，没有哪个设备能够支撑住。拿 BT 下载来说，伪造一些热门视频的种子，发布到搜索引擎，就足以骗到许多用户和流量了，但是这只是基础攻击。 高级的 P2P 攻击，是直接欺骗资源管理服务器。如迅雷客户端会把自己发现的资源上传到资源管理服务器，然后推送给其它需要下载相同资源的用户，这样，一个链接就发布出去。通过协议逆向，攻击者伪造出大批量的热门资源信息通过资源管理中心分发出去，瞬间就可以传遍整个 P2P 网络。更为恐怖的是，这种攻击是无法停止的，即使是攻击者自身也无法停止，攻击一直持续到 P2P 官方发现问题更新服务器且下载用户重启下载软件为止。 最后总结下，DDoS 不可能防的住，就好比你的店只能容纳 50 人，黑社会有 100 人，你就换一家大店，能容纳 500 人，然后黑社会又找来了 1000 人，这种堆人头的做法就是 DDoS 本质上的攻防之道，「道高一尺，魔高一丈，魔高一尺，道高一丈」，讲真，必要的时候就答应勒索你的人的条件吧，实在不行就报警吧。 流量劫持 流量劫持应该算是黑产行业的一大经济支柱了吧？简直是让人恶心到吐，不吐槽了，还是继续谈干货吧，流量劫持基本分两种：DNS 劫持 和 HTTP 劫持，目的都是一样的，就是当用户访问 zoumiaojiang.com 的时候，给你展示的并不是或者不完全是 zoumiaojiang.com 提供的 “内容”。 DNS 劫持 DNS 劫持，也叫做域名劫持，可以这么理解，「你打了一辆车想去商场吃饭，结果你打的车是小作坊派来的，直接给你拉到小作坊去了」，DNS 的作用是把网络地址域名对应到真实的计算机能够识别的 IP 地址，以便计算机能够进一步通信，传递网址和内容等。如果当用户通过某一个域名访问一个站点的时候，被篡改的 DNS 服务器返回的是一个恶意的钓鱼站点的 IP，用户就被劫持到了恶意钓鱼站点，然后继而会被钓鱼输入各种账号密码信息，泄漏隐私。 dns劫持 这类劫持，要不就是网络运营商搞的鬼，一般小的网络运营商与黑产勾结会劫持 DNS，要不就是电脑中毒，被恶意篡改了路由器的 DNS 配置，基本上做为开发者或站长却是很难察觉的，除非有用户反馈，现在升级版的 DNS 劫持还可以对特定用户、特定区域等使用了用户画像进行筛选用户劫持的办法，另外这类广告显示更加随机更小，一般站长除非用户投诉否则很难觉察到，就算觉察到了取证举报更难。无论如何，如果接到有 DNS 劫持的反馈，一定要做好以下几件事： 取证很重要，时间、地点、IP、拨号账户、截屏、URL 地址等一定要有。 可以跟劫持区域的电信运营商进行投诉反馈。 如果投诉反馈无效，直接去工信部投诉，一般来说会加白你的域名。 HTTP 劫持 HTTP 劫持您可以这么理解，「你打了一辆车想去商场吃饭，结果司机跟你一路给你递小作坊的广告」，HTTP 劫持主要是当用户访问某个站点的时候会经过运营商网络，而不法运营商和黑产勾结能够截获 HTTP 请求返回内容，并且能够篡改内容，然后再返回给用户，从而实现劫持页面，轻则插入小广告，重则直接篡改成钓鱼网站页面骗用户隐私。能够实施流量劫持的根本原因，是 HTTP 协议没有办法对通信对方的身份进行校验以及对数据完整性进行校验。如果能解决这个问题，则流量劫持将无法轻易发生。所以防止 HTTP 劫持的方法只有将内容加密，让劫持者无法破解篡改，这样就可以防止 HTTP 劫持了。 HTTPS 协议就是一种基于 SSL 协议的安全加密网络应用层协议，可以很好的防止 HTTP 劫持。这里有篇 文章 讲的不错。HTTPS 在这就不深讲了，后面有机会我会单独好好讲讲 HTTPS。如果不想站点被 HTTP 劫持，赶紧将你的站点全站改造成 HTTPS 吧。 服务器漏洞 服务器除了以上提到的那些大名鼎鼎的漏洞和臭名昭著的攻击以外，其实还有很多其他的漏洞，往往也很容易被忽视，在这个小节也稍微介绍几种。 越权操作漏洞 如果你的系统是有登录控制的，那就要格外小心了，因为很有可能你的系统越权操作漏洞，越权操作漏洞可以简单的总结为 「A 用户能看到或者操作 B 用户的隐私内容」，如果你的系统中还有权限控制就更加需要小心了。所以每一个请求都需要做 userid 的判断 以下是一段有漏洞的后端示意代码： // ctx 为请求的 context 上下文let msgId = ctx.params.msgId;mysql.query('SELECT FROM msg_table WHERE msg_id = ?',[msgId]); 以上代码是任何人都可以查询到任何用户的消息，只要有 msg_id 就可以，这就是比较典型的越权漏洞，需要如下这么改进一下： // ctx 为请求的 context 上下文let msgId = ctx.params.msgId;let userId = ctx.session.userId; // 从会话中取出当前登陆的 userIdmysql.query('SELECT FROM msg_table WHERE msg_id = ? AND user_id = ?',[msgId, userId]); 嗯，大概就是这个意思，如果有更严格的权限控制，那在每个请求中凡是涉及到数据库的操作都需要先进行严格的验证，并且在设计数据库表的时候需要考虑进 userId 的账号关联以及权限关联。 目录遍历漏洞 目录遍历漏洞指通过在 URL 或参数中构造 …/，./ 和类似的跨父目录字符串的 ASCII 编码、unicode 编码等，完成目录跳转，读取操作系统各个目录下的敏感文件，也可以称作「任意文件读取漏洞」。 目录遍历漏洞原理：程序没有充分过滤用户输入的 …/ 之类的目录跳转符，导致用户可以通过提交目录跳转来遍历服务器上的任意文件。使用多个… 符号，不断向上跳转，最终停留在根 /，通过绝对路径去读取任意文件。 目录遍历漏洞几个示例和测试，一般构造 URL 然后使用浏览器直接访问，或者使用 Web 漏洞扫描工具检测，当然也可以自写程序测试。 http://somehost.com/../../../../../../../../../etc/passwdhttp://somehost.com/some/path?file=../../Windows/system.ini 借助 %00 空字符截断是一个比较经典的攻击手法http://somehost.com/some/path?file=../../Windows/system.ini%00.js 使用了 IIS 的脚本目录来移动目录并执行指令http://somehost.com/scripts/..%5c../Windows/System32/cmd.exe?/c+dir+c:\ 防御 方法就是需要对 URL 或者参数进行 …/，./ 等字符的转义过滤。 物理路径泄漏 物理路径泄露属于低风险等级缺陷，它的危害一般被描述为「攻击者可以利用此漏洞得到信息，来对系统进一步地攻击」，通常都是系统报错 500 的错误信息直接返回到页面可见导致的漏洞。得到物理路径有些时候它能给攻击者带来一些有用的信息，比如说：可以大致了解系统的文件目录结构；可以看出系统所使用的第三方软件；也说不定会得到一个合法的用户名（因为很多人把自己的用户名作为网站的目录名）。 防止这种泄漏的方法就是做好后端程序的出错处理，定制特殊的 500 报错页面。 源码暴露漏洞 和物理路径泄露类似，就是攻击者可以通过请求直接获取到你站点的后端源代码，然后就可以对系统进一步研究攻击。那么导致源代码暴露的原因是什么呢？基本上就是发生在服务器配置上了，服务器可以设置哪些路径的文件才可以被直接访问的，这里给一个 koa 服务起的例子，正常的 koa 服务器可以通过 koa-static 中间件去指定静态资源的目录，好让静态资源可以通过路径的路由访问。比如你的系统源代码目录是这样的： |- project|- src|- static|- ...|- server.js 你想要将 static 的文件夹配成静态资源目录，你应该会在 server.js 做如下配置： const Koa = require('koa');const serve = require('koa-static');const app = new Koa();app.use(serve(__dirname + '/project/static')); 但是如果配错了静态资源的目录，可能就出大事了，比如： // ...app.use(serve(__dirname + '/project')); 这样所有的源代码都可以通过路由访问到了，所有的服务器都提供了静态资源机制，所以在通过服务器配置静态资源目录和路径的时候，一定要注意检验，不然很可能产生漏洞。 最后，希望 Web 开发者们能够管理好自己的代码隐私，注意代码安全问题，比如不要将产品的含有敏感信息的代码放到第三方外部站点或者暴露给外部用户，尤其是前端代码，私钥类似的保密性的东西不要直接输出在代码里或者页面中。也许还有很多值得注意的点，但是归根结底还是绷住安全那根弦，对待每一行代码都要多多推敲。 请关注我的订阅号 本篇文章为转载内容。原文链接：https://blog.csdn.net/MrCoderStack/article/details/88547919。 该文由互联网用户投稿提供，文中观点代表作者本人意见，并不代表本站的立场。 作为信息平台，本站仅提供文章转载服务，并不拥有其所有权，也不对文章内容的真实性、准确性和合法性承担责任。 如发现本文存在侵权、违法、违规或事实不符的情况，请及时联系我们，我们将第一时间进行核实并删除相应内容。

...看一下发布订阅命令的使用方法。 订阅者订阅频道：可以一次订阅多个，比如这个客户端订阅了 3 个频道。 subscribe channel-1 channel-2 channel-3 发布者可以向指定频道发布消息(并不支持一次向多个频道发送消息): publish channel-1 2673 取消订阅(不能在订阅状态下使用): unsubscribe channel-1 1.2.2 按规则(Pattern)订阅频道 支持 ?和 占位符。? 代表一个字符， 代表 0 个或者多个字符。 消费端 1，关注运动信息: psubscribe sport 消费端 2，关注所有新闻: psubscribe news 消费端 3，关注天气新闻: psubscribe news-weather 生产者，发布 3 条信息 publish news-sport yaoming publish news-music jaychou publish news-weather rain 2、Redis 事务 2.1 为什么要用事务 我们知道 Redis 的单个命令是原子性的(比如 get set mget mset)，如果涉及到多个命令的时候，需要把多个命令作为一个不可分割的处理序列，就需要用到事务。 例如我们之前说的用 setnx 实现分布式锁，我们先 set，然后设置对 key 设置 expire， 防止 del 发生异常的时候锁不会被释放，业务处理完了以后再 del，这三个动作我们就希望它们作为一组命令执行。 Redis 的事务有两个特点: 1、按进入队列的顺序执行。 2、不会受到其他客户端的请求的影响。 Redis 的事务涉及到四个命令:multi(开启事务)，exec(执行事务)，discard (取消事务)，watch(监视) 2.2 事务的用法 案例场景:tom 和 mic 各有 1000 元，tom 需要向 mic 转账 100 元。tom 的账户余额减少 100 元，mic 的账户余额增加 100 元。 通过 multi 的命令开启事务。事务不能嵌套，多个 multi 命令效果一样。 multi 执行后，客户端可以继续向服务器发送任意多条命令，这些命令不会立即被执行，而是被放到一个队列中，当 exec 命令被调用时，所有队列中的命令才会被执行。 通过 exec 的命令执行事务。如果没有执行 exec，所有的命令都不会被执行。如果中途不想执行事务了，怎么办? 可以调用 discard 可以清空事务队列，放弃执行。 2.3 watch命令 在 Redis 中还提供了一个 watch 命令。 它可以为 Redis 事务提供 CAS 乐观锁行为(Check and Set / Compare and Swap)，也就是多个线程更新变量的时候，会跟原值做比较，只有它没有被其他线程修改的情况下，才更新成新的值。 我们可以用 watch 监视一个或者多个 key，如果开启事务之后，至少有一个被监视 key 键在 exec 执行之前被修改了，那么整个事务都会被取消(key 提前过期除外)。可以用 unwatch 取消。 2.4 事务可能遇到的问题 我们把事务执行遇到的问题分成两种，一种是在执行 exec 之前发生错误，一种是在执行 exec 之后发生错误。 2.4.1 在执行 exec 之前发生错误 比如：入队的命令存在语法错误，包括参数数量，参数名等等(编译器错误)。 在这种情况下事务会被拒绝执行，也就是队列中所有的命令都不会得到执行。 2.4.2 在执行 exec 之后发生错误 比如，类型错误，比如对 String 使用了 Hash 的命令，这是一种运行时错误。 最后我们发现 set k1 1 的命令是成功的，也就是在这种发生了运行时异常的情况下， 只有错误的命令没有被执行，但是其他命令没有受到影响。 这个显然不符合我们对原子性的定义，也就是我们没办法用 Redis 的这种事务机制来实现原子性，保证数据的一致。 3、Lua脚本 Lua/ˈluə/是一种轻量级脚本语言，它是用 C 语言编写的，跟数据的存储过程有点类似。 使用 Lua 脚本来执行 Redis 命令的好处: 1、一次发送多个命令，减少网络开销。 2、Redis 会将整个脚本作为一个整体执行，不会被其他请求打断，保持原子性。 3、对于复杂的组合命令，我们可以放在文件中，可以实现程序之间的命令集复用。 3.1 在Redis中调用Lua脚本 使用 eval /ɪ’væl/ 方法，语法格式: redis> eval lua-script key-num [key1 key2 key3 ....] [value1 value2 value3 ....] eval代表执行Lua语言的命令。 lua-script代表Lua语言脚本内容。 key-num表示参数中有多少个key，需要注意的是Redis中key是从1开始的，如果没有key的参数，那么写0。 [key1key2key3…]是key作为参数传递给Lua语言，也可以不填，但是需要和key-num的个数对应起来。 [value1 value2 value3 …]这些参数传递给 Lua 语言，它们是可填可不填的。 示例，返回一个字符串，0 个参数: redis> eval "return 'Hello World'" 0 3.2 在Lua脚本中调用Redis命令 使用 redis.call(command, key [param1, param2…])进行操作。语法格式: redis> eval "redis.call('set',KEYS[1],ARGV[1])" 1 lua-key lua-value command是命令，包括set、get、del等。 key是被操作的键。 param1,param2…代表给key的参数。 注意跟 Java 不一样，定义只有形参，调用只有实参。 Lua 是在调用时用 key 表示形参，argv 表示参数值(实参)。 3.2.1 设置键值对 在 Redis 中调用 Lua 脚本执行 Redis 命令 redis> eval "return redis.call('set',KEYS[1],ARGV[1])" 1 gupao 2673 redis> get gupao 以上命令等价于 set gupao 2673。 在 redis-cli 中直接写 Lua 脚本不够方便，也不能实现编辑和复用，通常我们会把脚本放在文件里面，然后执行这个文件。 3.2.2 在 Redis 中调用 Lua 脚本文件中的命令，操作 Redis 创建 Lua 脚本文件: cd /usr/local/soft/redis5.0.5/src vim gupao.lua Lua 脚本内容，先设置，再取值: cd /usr/local/soft/redis5.0.5/src redis-cli --eval gupao.lua 0 得到返回值: root@localhost src] redis-cli --eval gupao.lua 0 "lua666" 3.2.3 案例:对 IP 进行限流 需求：在 X 秒内只能访问 Y 次。 设计思路：用 key 记录 IP，用 value 记录访问次数。 拿到 IP 以后，对 IP+1。如果是第一次访问，对 key 设置过期时间(参数 1)。否则判断次数，超过限定的次数(参数 2)，返回 0。如果没有超过次数则返回 1。超过时间， key 过期之后，可以再次访问。 KEY[1]是 IP， ARGV[1]是过期时间 X，ARGV[2]是限制访问的次数 Y。 -- ip_limit.lua-- IP 限流，对某个 IP 频率进行限制 ，6 秒钟访问 10 次 local num=redis.call('incr',KEYS[1])if tonumber(num)==1 thenredis.call('expire',KEYS[1],ARGV[1])return 1elseif tonumber(num)>tonumber(ARGV[2]) thenreturn 0 elsereturn 1 end 6 秒钟内限制访问 10 次，调用测试(连续调用 10 次): ./redis-cli --eval "ip_limit.lua" app:ip:limit:192.168.8.111 , 6 10 app:ip:limit:192.168.8.111 是 key 值 ，后面是参数值，中间要加上一个空格和一个逗号，再加上一个空格 。 即:./redis-cli –eval [lua 脚本] [key…]空格,空格[args…] 多个参数之间用一个空格分割 。 代码:LuaTest.java 3.2.4 缓存 Lua 脚本 为什么要缓存 在脚本比较长的情况下，如果每次调用脚本都需要把整个脚本传给 Redis 服务端， 会产生比较大的网络开销。为了解决这个问题，Redis 提供了 EVALSHA 命令，允许开发者通过脚本内容的 SHA1 摘要来执行脚本。 如何缓存 Redis 在执行 script load 命令时会计算脚本的 SHA1 摘要并记录在脚本缓存中，执行 EVALSHA 命令时 Redis 会根据提供的摘要从脚本缓存中查找对应的脚本内容，如果找到了则执行脚本，否则会返回错误:“NOSCRIPT No matching script. Please use EVAL.” 127.0.0.1:6379> script load "return 'Hello World'" "470877a599ac74fbfda41caa908de682c5fc7d4b"127.0.0.1:6379> evalsha "470877a599ac74fbfda41caa908de682c5fc7d4b" 0 "Hello World" 3.2.5 自乘案例 Redis 有 incrby 这样的自增命令，但是没有自乘，比如乘以 3，乘以 5。我们可以写一个自乘的运算，让它乘以后面的参数： local curVal = redis.call("get", KEYS[1]) if curVal == false thencurVal = 0 elsecurVal = tonumber(curVal)endcurVal = curVal tonumber(ARGV[1]) redis.call("set", KEYS[1], curVal) return curVal 把这个脚本变成单行，语句之间使用分号隔开 local curVal = redis.call("get", KEYS[1]); if curVal == false then curVal = 0 else curVal = tonumber(curVal) end; curVal = curVal tonumber(ARGV[1]); redis.call("set", KEYS[1], curVal); return curVal script load ‘命令’ 127.0.0.1:6379> script load 'local curVal = redis.call("get", KEYS[1]); if curVal == false then curVal = 0 else curVal = tonumber(curVal) end; curVal = curVal tonumber(ARGV[1]); redis.call("set", KEYS[1], curVal); return curVal' "be4f93d8a5379e5e5b768a74e77c8a4eb0434441" 调用: 127.0.0.1:6379> set num 2OK127.0.0.1:6379> evalsha be4f93d8a5379e5e5b768a74e77c8a4eb0434441 1 num 6 (integer) 12 3.2.6 脚本超时 Redis 的指令执行本身是单线程的，这个线程还要执行客户端的 Lua 脚本，如果 Lua 脚本执行超时或者陷入了死循环，是不是没有办法为客户端提供服务了呢? eval 'while(true) do end' 0 为了防止某个脚本执行时间过长导致 Redis 无法提供服务，Redis 提供了 lua-time-limit 参数限制脚本的最长运行时间，默认为 5 秒钟。 lua-time-limit 5000(redis.conf 配置文件中) 当脚本运行时间超过这一限制后，Redis 将开始接受其他命令但不会执行(以确保脚本的原子性，因为此时脚本并没有被终止)，而是会返回“BUSY”错误。 Redis 提供了一个 script kill 的命令来中止脚本的执行。新开一个客户端: script kill 如果当前执行的 Lua 脚本对 Redis 的数据进行了修改(SET、DEL 等)，那么通过 script kill 命令是不能终止脚本运行的。 127.0.0.1:6379> eval "redis.call('set','gupao','666') while true do end" 0 因为要保证脚本运行的原子性，如果脚本执行了一部分终止，那就违背了脚本原子性的要求。最终要保证脚本要么都执行，要么都不执行。 127.0.0.1:6379> script kill(error) UNKILLABLE Sorry the script already executed write commands against the dataset. You can either wait the scripttermination or kill the server in a hard way using the SHUTDOWN NOSAVE command. 遇到这种情况，只能通过 shutdown nosave 命令来强行终止 redis。 shutdown nosave 和 shutdown 的区别在于 shutdown nosave 不会进行持久化操作，意味着发生在上一次快照后的数据库修改都会丢失。 4、Redis 为什么这么快? 4.1 Redis到底有多快？ 根据官方的数据，Redis 的 QPS 可以达到 10 万左右(每秒请求数)。 4.2 Redis为什么这么快? 总结:1)纯内存结构、2)单线程、3)多路复用 4.2.1 内存 KV 结构的内存数据库，时间复杂度 O(1)。 第二个，要实现这么高的并发性能，是不是要创建非常多的线程? 恰恰相反，Redis 是单线程的。 4.2.2 单线程 单线程有什么好处呢? 1、没有创建线程、销毁线程带来的消耗 2、避免了上线文切换导致的 CPU 消耗 3、避免了线程之间带来的竞争问题，例如加锁释放锁死锁等等 4.2.3 异步非阻塞 异步非阻塞 I/O，多路复用处理并发连接。 4.3 Redis为什么是单线程的? 不是白白浪费了 CPU 的资源吗? 因为单线程已经够用了，CPU 不是 redis 的瓶颈。Redis 的瓶颈最有可能是机器内存或者网络带宽。既然单线程容易实现，而且 CPU 不会成为瓶颈，那就顺理成章地采用单线程的方案了。 4.4 单线程为什么这么快? 因为 Redis 是基于内存的操作，我们先从内存开始说起。 4.4.1 虚拟存储器(虚拟内存 Vitual Memory) 名词解释:主存:内存;辅存:磁盘(硬盘) 计算机主存(内存)可看作一个由 M 个连续的字节大小的单元组成的数组，每个字节有一个唯一的地址，这个地址叫做物理地址(PA)。早期的计算机中，如果 CPU 需要内存，使用物理寻址，直接访问主存储器。 这种方式有几个弊端: 1、在多用户多任务操作系统中，所有的进程共享主存，如果每个进程都独占一块物理地址空间，主存很快就会被用完。我们希望在不同的时刻，不同的进程可以共用同一块物理地址空间。 2、如果所有进程都是直接访问物理内存，那么一个进程就可以修改其他进程的内存数据，导致物理地址空间被破坏，程序运行就会出现异常。 为了解决这些问题，我们就想了一个办法，在 CPU 和主存之间增加一个中间层。CPU 不再使用物理地址访问，而是访问一个虚拟地址，由这个中间层把地址转换成物理地址，最终获得数据。这个中间层就叫做虚拟存储器(Virtual Memory)。 具体的操作如下所示: 在每一个进程开始创建的时候，都会分配一段虚拟地址，然后通过虚拟地址和物理地址的映射来获取真实数据，这样进程就不会直接接触到物理地址，甚至不知道自己调用的哪块物理地址的数据。 目前，大多数操作系统都使用了虚拟内存，如 Windows 系统的虚拟内存、Linux 系统的交换空间等等。Windows 的虚拟内存(pagefile.sys)是磁盘空间的一部分。 在 32 位的系统上，虚拟地址空间大小是 2^32bit=4G。在 64 位系统上，最大虚拟地址空间大小是多少? 是不是 2^64bit=10241014TB=1024PB=16EB?实际上没有用到 64 位，因为用不到这么大的空间，而且会造成很大的系统开销。Linux 一般用低 48 位来表示虚拟地址空间，也就是 2^48bit=256T。 cat /proc/cpuinfo address sizes : 40 bits physical, 48 bits virtual 实际的物理内存可能远远小于虚拟内存的大小。 总结：引入虚拟内存，可以提供更大的地址空间，并且地址空间是连续的，使得程序编写、链接更加简单。并且可以对物理内存进行隔离，不同的进程操作互不影响。还可以通过把同一块物理内存映射到不同的虚拟地址空间实现内存共享。 4.4.2 用户空间和内核空间 为了避免用户进程直接操作内核，保证内核安全，操作系统将虚拟内存划分为两部分，一部分是内核空间(Kernel-space)/ˈkɜːnl /，一部分是用户空间(User-space)。 内核是操作系统的核心，独立于普通的应用程序，可以访问受保护的内存空间，也有访问底层硬件设备的权限。 内核空间中存放的是内核代码和数据，而进程的用户空间中存放的是用户程序的代码和数据。不管是内核空间还是用户空间，它们都处于虚拟空间中，都是对物理地址的映射。 在 Linux 系统中, 内核进程和用户进程所占的虚拟内存比例是 1:3。 当进程运行在内核空间时就处于内核态，而进程运行在用户空间时则处于用户态。 进程在内核空间以执行任意命令，调用系统的一切资源;在用户空间只能执行简单的运算，不能直接调用系统资源，必须通过系统接口(又称 system call)，才能向内核发出指令。 top 命令: us 代表 CPU 消耗在 User space 的时间百分比; sy 代表 CPU 消耗在 Kernel space 的时间百分比。 4.4.3 进程切换(上下文切换) 多任务操作系统是怎么实现运行远大于 CPU 数量的任务个数的? 当然，这些任务实际上并不是真的在同时运行，而是因为系统通过时间片分片算法，在很短的时间内，将 CPU 轮流分配给它们，造成多任务同时运行的错觉。 为了控制进程的执行，内核必须有能力挂起正在 CPU 上运行的进程，并恢复以前挂起的某个进程的执行。这种行为被称为进程切换。 什么叫上下文? 在每个任务运行前，CPU 都需要知道任务从哪里加载、又从哪里开始运行，也就是说，需要系统事先帮它设置好 CPU 寄存器和程序计数器(ProgramCounter)，这个叫做 CPU 的上下文。 而这些保存下来的上下文，会存储在系统内核中，并在任务重新调度执行时再次加载进来。这样就能保证任务原来的状态不受影响，让任务看起来还是连续运行。 在切换上下文的时候，需要完成一系列的工作，这是一个很消耗资源的操作。 4.4.4 进程的阻塞 正在运行的进程由于提出系统服务请求(如 I/O 操作)，但因为某种原因未得到操作系统的立即响应，该进程只能把自己变成阻塞状态，等待相应的事件出现后才被唤醒。 进程在阻塞状态不占用 CPU 资源。 4.4.5 文件描述符 FD Linux 系统将所有设备都当作文件来处理，而 Linux 用文件描述符来标识每个文件对象。 文件描述符(File Descriptor)是内核为了高效管理已被打开的文件所创建的索引，用于指向被打开的文件，所有执行 I/O 操作的系统调用都通过文件描述符;文件描述符是一个简单的非负整数，用以表明每个被进程打开的文件。 Linux 系统里面有三个标准文件描述符。 0:标准输入(键盘); 1:标准输出(显示器); 2:标准错误输出(显示器)。 4.4.6 传统 I/O 数据拷贝 以读操作为例: 当应用程序执行 read 系统调用读取文件描述符(FD)的时候，如果这块数据已经存在于用户进程的页内存中，就直接从内存中读取数据。如果数据不存在，则先将数据从磁盘加载数据到内核缓冲区中，再从内核缓冲区拷贝到用户进程的页内存中。(两次拷贝，两次 user 和 kernel 的上下文切换)。 I/O 的阻塞到底阻塞在哪里? 4.4.7 Blocking I/O 当使用 read 或 write 对某个文件描述符进行过读写时，如果当前 FD 不可读，系统就不会对其他的操作做出响应。从设备复制数据到内核缓冲区是阻塞的，从内核缓冲区拷贝到用户空间，也是阻塞的，直到 copy complete，内核返回结果，用户进程才解除 block 的状态。 为了解决阻塞的问题，我们有几个思路。 1、在服务端创建多个线程或者使用线程池，但是在高并发的情况下需要的线程会很多，系统无法承受，而且创建和释放线程都需要消耗资源。 2、由请求方定期轮询，在数据准备完毕后再从内核缓存缓冲区复制数据到用户空间 (非阻塞式 I/O)，这种方式会存在一定的延迟。 能不能用一个线程处理多个客户端请求? 4.4.8 I/O 多路复用(I/O Multiplexing) I/O 指的是网络 I/O。 多路指的是多个 TCP 连接(Socket 或 Channel)。 复用指的是复用一个或多个线程。它的基本原理就是不再由应用程序自己监视连接，而是由内核替应用程序监视文件描述符。 客户端在操作的时候，会产生具有不同事件类型的 socket。在服务端，I/O 多路复用程序(I/O Multiplexing Module)会把消息放入队列中，然后通过文件事件分派器(File event Dispatcher)，转发到不同的事件处理器中。 多路复用有很多的实现，以 select 为例，当用户进程调用了多路复用器，进程会被阻塞。内核会监视多路复用器负责的所有 socket，当任何一个 socket 的数据准备好了，多路复用器就会返回。这时候用户进程再调用 read 操作，把数据从内核缓冲区拷贝到用户空间。 所以，I/O 多路复用的特点是通过一种机制一个进程能同时等待多个文件描述符，而这些文件描述符(套接字描述符)其中的任意一个进入读就绪(readable)状态，select() 函数就可以返回。 Redis 的多路复用， 提供了 select, epoll, evport, kqueue 几种选择，在编译的时 候来选择一种。 evport 是 Solaris 系统内核提供支持的; epoll 是 LINUX 系统内核提供支持的; kqueue 是 Mac 系统提供支持的; select 是 POSIX 提供的，一般的操作系统都有支撑(保底方案); 源码 ae_epoll.c、ae_select.c、ae_kqueue.c、ae_evport.c 5、内存回收 Reids 所有的数据都是存储在内存中的，在某些情况下需要对占用的内存空间进行回 收。内存回收主要分为两类，一类是 key 过期，一类是内存使用达到上限(max_memory) 触发内存淘汰。 5.1 过期策略 要实现 key 过期，我们有几种思路。 5.1.1 定时过期(主动淘汰) 每个设置过期时间的 key 都需要创建一个定时器，到过期时间就会立即清除。该策略可以立即清除过期的数据，对内存很友好;但是会占用大量的 CPU 资源去处理过期的 数据，从而影响缓存的响应时间和吞吐量。 5.1.2 惰性过期(被动淘汰) 只有当访问一个 key 时，才会判断该 key 是否已过期，过期则清除。该策略可以最大化地节省 CPU 资源，却对内存非常不友好。极端情况可能出现大量的过期 key 没有再次被访问，从而不会被清除，占用大量内存。 例如 String，在 getCommand 里面会调用 expireIfNeeded server.c expireIfNeeded(redisDb db, robj key) 第二种情况，每次写入 key 时，发现内存不够，调用 activeExpireCycle 释放一部分内存。 expire.c activeExpireCycle(int type) 5.1.3 定期过期 源码:server.h typedef struct redisDb { dict dict; / 所有的键值对 /dict expires; / 设置了过期时间的键值对 /dict blocking_keys; dict ready_keys; dict watched_keys; int id;long long avg_ttl;list defrag_later; } redisDb; 每隔一定的时间，会扫描一定数量的数据库的 expires 字典中一定数量的 key，并清除其中已过期的 key。该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和每次扫描的限定耗时，可以在不同情况下使得 CPU 和内存资源达到最优的平衡效果。 Redis 中同时使用了惰性过期和定期过期两种过期策略。 5.2 淘汰策略 Redis 的内存淘汰策略，是指当内存使用达到最大内存极限时，需要使用淘汰算法来决定清理掉哪些数据，以保证新数据的存入。 5.2.1 最大内存设置 redis.conf 参数配置: maxmemory <bytes> 如果不设置 maxmemory 或者设置为 0，64 位系统不限制内存，32 位系统最多使用 3GB 内存。 动态修改: redis> config set maxmemory 2GB 到达最大内存以后怎么办? 5.2.2 淘汰策略 https://redis.io/topics/lru-cache redis.conf maxmemory-policy noeviction 先从算法来看: LRU，Least Recently Used:最近最少使用。判断最近被使用的时间，目前最远的数据优先被淘汰。 LFU，Least Frequently Used，最不常用，4.0 版本新增。 random，随机删除。 如果没有符合前提条件的 key 被淘汰，那么 volatile-lru、volatile-random、 volatile-ttl 相当于 noeviction(不做内存回收)。 动态修改淘汰策略: redis> config set maxmemory-policy volatile-lru 建议使用 volatile-lru，在保证正常服务的情况下，优先删除最近最少使用的 key。 5.2.3 LRU 淘汰原理 问题：如果基于传统 LRU 算法实现 Redis LRU 会有什么问题? 需要额外的数据结构存储，消耗内存。 Redis LRU 对传统的 LRU 算法进行了改良，通过随机采样来调整算法的精度。如果淘汰策略是 LRU，则根据配置的采样值 maxmemory_samples(默认是 5 个), 随机从数据库中选择 m 个 key, 淘汰其中热度最低的 key 对应的缓存数据。所以采样参数m配置的数值越大, 就越能精确的查找到待淘汰的缓存数据,但是也消耗更多的CPU计算,执行效率降低。 问题：如何找出热度最低的数据? Redis 中所有对象结构都有一个 lru 字段, 且使用了 unsigned 的低 24 位，这个字段用来记录对象的热度。对象被创建时会记录 lru 值。在被访问的时候也会更新 lru 的值。 但是不是获取系统当前的时间戳，而是设置为全局变量 server.lruclock 的值。 源码：server.h typedef struct redisObject {unsigned type:4;unsigned encoding:4;unsigned lru:LRU_BITS;int refcount;void ptr; } robj; server.lruclock 的值怎么来的? Redis 中有个定时处理的函数 serverCron，默认每 100 毫秒调用函数 updateCachedTime 更新一次全局变量的 server.lruclock 的值，它记录的是当前 unix 时间戳。 源码:server.c void updateCachedTime(void) { time_t unixtime = time(NULL); atomicSet(server.unixtime,unixtime); server.mstime = mstime();​struct tm tm; localtime_r(&server.unixtime,&tm);server.daylight_active = tm.tm_isdst; } 问题:为什么不获取精确的时间而是放在全局变量中?不会有延迟的问题吗? 这样函数 lookupKey 中更新数据的 lru 热度值时,就不用每次调用系统函数 time，可以提高执行效率。 OK，当对象里面已经有了 LRU 字段的值，就可以评估对象的热度了。 函数 estimateObjectIdleTime 评估指定对象的 lru 热度，思想就是对象的 lru 值和全局的 server.lruclock 的差值越大(越久没有得到更新)，该对象热度越低。 源码 evict.c / Given an object returns the min number of milliseconds the object was never requested, using an approximated LRU algorithm. /unsigned long long estimateObjectIdleTime(robj o) {unsigned long long lruclock = LRU_CLOCK(); if (lruclock >= o->lru) {return (lruclock - o->lru) LRU_CLOCK_RESOLUTION; } else {return (lruclock + (LRU_CLOCK_MAX - o->lru)) LRU_CLOCK_RESOLUTION;} } server.lruclock 只有 24 位，按秒为单位来表示才能存储 194 天。当超过 24bit 能表 示的最大时间的时候，它会从头开始计算。 server.h define LRU_CLOCK_MAX ((1<<LRU_BITS)-1) / Max value of obj->lru / 在这种情况下，可能会出现对象的 lru 大于 server.lruclock 的情况，如果这种情况 出现那么就两个相加而不是相减来求最久的 key。 为什么不用常规的哈希表+双向链表的方式实现?需要额外的数据结构，消耗资源。而 Redis LRU 算法在 sample 为 10 的情况下，已经能接近传统 LRU 算法了。 问题:除了消耗资源之外，传统 LRU 还有什么问题? 如图，假设 A 在 10 秒内被访问了 5 次，而 B 在 10 秒内被访问了 3 次。因为 B 最后一次被访问的时间比 A 要晚，在同等的情况下，A 反而先被回收。 问题:要实现基于访问频率的淘汰机制，怎么做? 5.2.4 LFU server.h typedef struct redisObject {unsigned type:4;unsigned encoding:4;unsigned lru:LRU_BITS;int refcount;void ptr; } robj; 当这 24 bits 用作 LFU 时，其被分为两部分: 高 16 位用来记录访问时间(单位为分钟，ldt，last decrement time) 低 8 位用来记录访问频率，简称 counter(logc，logistic counter) counter 是用基于概率的对数计数器实现的，8 位可以表示百万次的访问频率。 对象被读写的时候，lfu 的值会被更新。 db.c——lookupKey void updateLFU(robj val) {unsigned long counter = LFUDecrAndReturn(val); counter = LFULogIncr(counter);val->lru = (LFUGetTimeInMinutes()<<8) | counter;} 增长的速率由，lfu-log-factor 越大，counter 增长的越慢 redis.conf 配置文件。 lfu-log-factor 10 如果计数器只会递增不会递减，也不能体现对象的热度。没有被访问的时候，计数器怎么递减呢? 减少的值由衰减因子 lfu-decay-time(分钟)来控制，如果值是 1 的话，N 分钟没有访问就要减少 N。 redis.conf 配置文件 lfu-decay-time 1 6、持久化机制 https://redis.io/topics/persistence Redis 速度快，很大一部分原因是因为它所有的数据都存储在内存中。如果断电或者宕机，都会导致内存中的数据丢失。为了实现重启后数据不丢失，Redis 提供了两种持久化的方案，一种是 RDB 快照(Redis DataBase)，一种是 AOF(Append Only File)。 6.1 RDB RDB 是 Redis 默认的持久化方案。当满足一定条件的时候，会把当前内存中的数据写入磁盘，生成一个快照文件 dump.rdb。Redis 重启会通过加载 dump.rdb 文件恢复数据。 什么时候写入 rdb 文件? 6.1.1 RDB 触发 1、自动触发 a)配置规则触发。 redis.conf， SNAPSHOTTING，其中定义了触发把数据保存到磁盘的触发频率。 如果不需要 RDB 方案，注释 save 或者配置成空字符串""。 save 900 1 900 秒内至少有一个 key 被修改(包括添加) save 300 10 400 秒内至少有 10 个 key 被修改save 60 10000 60 秒内至少有 10000 个 key 被修改 注意上面的配置是不冲突的，只要满足任意一个都会触发。 RDB 文件位置和目录: 文件路径，dir ./ 文件名称dbfilename dump.rdb 是否是LZF压缩rdb文件 rdbcompression yes 开启数据校验 rdbchecksum yes 问题：为什么停止 Redis 服务的时候没有 save，重启数据还在? RDB 还有两种触发方式: b)shutdown 触发，保证服务器正常关闭。 c)flushall，RDB 文件是空的，没什么意义(删掉 dump.rdb 演示一下)。 2、手动触发 如果我们需要重启服务或者迁移数据，这个时候就需要手动触 RDB 快照保存。Redis 提供了两条命令: a)save save 在生成快照的时候会阻塞当前 Redis 服务器， Redis 不能处理其他命令。如果内存中的数据比较多，会造成 Redis 长时间的阻塞。生产环境不建议使用这个命令。 为了解决这个问题，Redis 提供了第二种方式。 执行 bgsave 时，Redis 会在后台异步进行快照操作，快照同时还可以响应客户端请求。 具体操作是 Redis 进程执行 fork 操作创建子进程(copy-on-write)，RDB 持久化过程由子进程负责，完成后自动结束。它不会记录 fork 之后后续的命令。阻塞只发生在 fork 阶段，一般时间很短。 用 lastsave 命令可以查看最近一次成功生成快照的时间。 6.1.2 RDB 数据的恢复(演示) 1、shutdown 持久化添加键值 添加键值 redis> set k1 1 redis> set k2 2 redis> set k3 3 redis> set k4 4 redis> set k5 5 停服务器，触发 save redis> shutdown 备份 dump.rdb 文件 cp dump.rdb dump.rdb.bak 启动服务器 /usr/local/soft/redis-5.0.5/src/redis-server /usr/local/soft/redis-5.0.5/redis.conf 啥都没有: redis> keys 3、通过备份文件恢复数据停服务器 redis> shutdown 重命名备份文件 mv dump.rdb.bak dump.rdb 启动服务器 /usr/local/soft/redis-5.0.5/src/redis-server /usr/local/soft/redis-5.0.5/redis.conf 查看数据 redis> keys 6.1.3 RDB 文件的优势和劣势 一、优势 1.RDB 是一个非常紧凑(compact)的文件，它保存了 redis 在某个时间点上的数据集。这种文件非常适合用于进行备份和灾难恢复。 2.生成 RDB 文件的时候，redis 主进程会 fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘 IO 操作。 3.RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。 二、劣势 1、RDB 方式数据没办法做到实时持久化/秒级持久化。因为 bgsave 每次运行都要执行 fork 操作创建子进程，频繁执行成本过高。 2、在一定间隔时间做一次备份，所以如果 redis 意外 down 掉的话，就会丢失最后一次快照之后的所有修改(数据有丢失)。 如果数据相对来说比较重要，希望将损失降到最小，则可以使用 AOF 方式进行持久化。 6.2 AOF Append Only File AOF:Redis 默认不开启。AOF 采用日志的形式来记录每个写操作，并追加到文件中。开启后，执行更改 Redis 数据的命令时，就会把命令写入到 AOF 文件中。 Redis 重启时会根据日志文件的内容把写指令从前到后执行一次以完成数据的恢复工作。 6.2.1 AOF 配置 配置文件 redis.conf 开关appendonly no 文件名appendfilename "appendonly.aof" AOF 文件的内容(vim 查看): 问题：数据都是实时持久化到磁盘吗? 由于操作系统的缓存机制，AOF 数据并没有真正地写入硬盘，而是进入了系统的硬盘缓存。什么时候把缓冲区的内容写入到 AOF 文件? 问题:文件越来越大，怎么办? 由于 AOF 持久化是 Redis 不断将写命令记录到 AOF 文件中，随着 Redis 不断的进行，AOF 的文件会越来越大，文件越大，占用服务器内存越大以及 AOF 恢复要求时间越长。 例如 set xxx 666，执行 1000 次，结果都是 xxx=666。 为了解决这个问题，Redis 新增了重写机制，当 AOF 文件的大小超过所设定的阈值时，Redis 就会启动 AOF 文件的内容压缩，只保留可以恢复数据的最小指令集。 可以使用命令 bgrewriteaof 来重写。 AOF 文件重写并不是对原文件进行重新整理，而是直接读取服务器现有的键值对，然后用一条命令去代替之前记录这个键值对的多条命令，生成一个新的文件后去替换原来的 AOF 文件。 重写触发机制 auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb 问题:重写过程中，AOF 文件被更改了怎么办? 另外有两个与 AOF 相关的参数: 6.2.2 AOF 数据恢复 重启 Redis 之后就会进行 AOF 文件的恢复。 6.2.3 AOF 优势与劣势 优点: 1、AOF 持久化的方法提供了多种的同步频率，即使使用默认的同步频率每秒同步一次，Redis 最多也就丢失 1 秒的数据而已。 缺点: 1、对于具有相同数据的的 Redis，AOF 文件通常会比 RDB 文件体积更大(RDB 存的是数据快照)。 2、虽然 AOF 提供了多种同步的频率，默认情况下，每秒同步一次的频率也具有较高的性能。在高并发的情况下，RDB 比 AOF 具好更好的性能保证。 6.3 两种方案比较 那么对于 AOF 和 RDB 两种持久化方式，我们应该如何选择呢? 如果可以忍受一小段时间内数据的丢失，毫无疑问使用 RDB 是最好的，定时生成 RDB 快照(snapshot)非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快。 否则就使用 AOF 重写。但是一般情况下建议不要单独使用某一种持久化机制，而是应该两种一起用，在这种情况下,当 redis 重启的时候会优先载入 AOF 文件来恢复原始的数据，因为在通常情况下 AOF 文件保存的数据集要比 RDB 文件保存的数据集要完整。 本篇文章为转载内容。原文链接：https://blog.csdn.net/zhoutaochun/article/details/120075092。 该文由互联网用户投稿提供，文中观点代表作者本人意见，并不代表本站的立场。 作为信息平台，本站仅提供文章转载服务，并不拥有其所有权，也不对文章内容的真实性、准确性和合法性承担责任。 如发现本文存在侵权、违法、违规或事实不符的情况，请及时联系我们，我们将第一时间进行核实并删除相应内容。

...页右边，向下滑有目录索引，可以根据标题跳转到你想看的内容 如果右边没有就找找左边 上一节：JUC锁，一些面试题和源码讲解 1、引用 java引用共4种，强软弱虚 强引用：我们普通的new一个对象，就是强引用，只有它指向为空了，或者已经没用了，才会被回收 软引用：JVM内存不够了，就回收软引用 弱引用：只要碰见垃圾回收器(System.gc())，就被回收 虚引用：对象当被回收时，会将其放在队列中 1、软引用 / 软引用 软引用是用来描述一些还有用但并非必须的对象。 对于软引用关联着的对象，在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围进行第二次回收。 如果这次回收还没有足够的内存，才会抛出内存溢出异常。 -Xmx20M/import java.lang.ref.SoftReference;public class T02_SoftReference {public static void main(String[] args) {SoftReference<byte[]> m = new SoftReference<>(new byte[1024102410]);//创建软引用，分配10M//m = null;System.out.println(m.get());//获取System.gc();//垃圾回收try {Thread.sleep(500);} catch (InterruptedException e) {e.printStackTrace();}System.out.println(m.get());//再分配一个数组，heap将装不下，这时候系统会垃圾回收，先回收一次，如果不够，会把软引用干掉byte[] b = new byte[1024102415];System.out.println(m.get());} }//软引用非常适合缓存使用 2、弱引用 public class M {@Overrideprotected void finalize() throws Throwable {System.out.println("finalize");} } 上图中，tl对象强引用指向ThreadLocal，map中key弱引用指向ThreadLocal，当tl=null时，强引用消失，此时弱引用也将自动被回收，但是此时key=null，value指向10M这个就永远访问不到，既内存泄露 下图中，18行到20行为解决内存泄露问题的，那就是通过remove()将它消除了 / 弱引用遭到gc就会回收/import java.lang.ref.WeakReference;public class T03_WeakReference {public static void main(String[] args) {WeakReference<M> m = new WeakReference<>(new M());System.out.println(m.get());System.gc();System.out.println(m.get());ThreadLocal<M> tl = new ThreadLocal<>();tl.set(new M());tl.remove();} } 3、虚引用 虚引用 虚引用不是给开发人员用的，一般是给写JVM（java虚拟机，没有它java程序运行不了），Netty等技术大牛用的 虚引用，对象当被回收时，会将其放在队列中，此时我们监听到队列中有新值了，就知道有虚引用被回收了 此时我们要做相应的处理，虚引用指向的值，是无法直接get()获取的 虚引用使用场景 一般情况（其它情况暂时没什么用），虚引用指向堆外内存(直接被操作系统管理的内存)，JVM无法对其回收 当虚引用对象被回收时，JVM的垃圾回收无法自动回收堆外内存， 但是此时，虚引用对象被回收，会将其放在队列中 操作人员，看到队列中有对象被回收，就进行相应操作，回收堆内存 如何回收堆外内存 C和C++有函数可以用 java现在也提供了Unsafe类可以操作堆外内存，具体请参考上一篇博客，总之，JDK1.8只能通过反射来用，JDK1.9以上可以通过new Unsafe对象来用 Unsafe类的方法有： copyMemory():直接访问内存 allocateMemory():直接分配内存，这就必须手动回收内存了 freeMemory():回收内存 下面是一个虚引用例子，自己看吧，懂得自然懂，现在看不懂的，先收藏或者保存上，以后回来看 / 一个对象是否有虚引用的存在，完全不会对其生存时间构成影响， 也无法通过虚引用来获取一个对象的实例。 为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。 虚引用和弱引用对关联对象的回收都不会产生影响，如果只有虚引用活着弱引用关联着对象， 那么这个对象就会被回收。它们的不同之处在于弱引用的get方法，虚引用的get方法始终返回null, 弱引用可以使用ReferenceQueue,虚引用必须配合ReferenceQueue使用。 jdk中直接内存的回收就用到虚引用，由于jvm自动内存管理的范围是堆内存， 而直接内存是在堆内存之外（其实是内存映射文件，自行去理解虚拟内存空间的相关概念）， 所以直接内存的分配和回收都是有Unsafe类去操作，java在申请一块直接内存之后， 会在堆内存分配一个对象保存这个堆外内存的引用， 这个对象被垃圾收集器管理，一旦这个对象被回收， 相应的用户线程会收到通知并对直接内存进行清理工作。 事实上，虚引用有一个很重要的用途就是用来做堆外内存的释放， DirectByteBuffer就是通过虚引用来实现堆外内存的释放的。/import java.lang.ref.PhantomReference;import java.lang.ref.Reference;import java.lang.ref.ReferenceQueue;import java.util.LinkedList;import java.util.List;public class T04_PhantomReference {private static final List<Object> LIST = new LinkedList<>();private static final ReferenceQueue<M> QUEUE = new ReferenceQueue<>();public static void main(String[] args) {PhantomReference<M> phantomReference = new PhantomReference<>(new M(), QUEUE);new Thread(() -> {while (true) {LIST.add(new byte[1024 1024]);try {Thread.sleep(1000);} catch (InterruptedException e) {e.printStackTrace();Thread.currentThread().interrupt();}System.out.println(phantomReference.get());} }).start();new Thread(() -> {while (true) {Reference<? extends M> poll = QUEUE.poll();if (poll != null) {System.out.println("--- 虚引用对象被jvm回收了 ---- " + poll);} }}).start();try {Thread.sleep(500);} catch (InterruptedException e) {e.printStackTrace();} }} 2、容器 1、发展历史(一定要了解) map容器你需要了解的历史 JDK早期，java提供了Vector和Hashtable两个容器，这两个容器，很多操作都加了锁Synchronized，对于某些不需要用锁的情况下，就显得十分影响性能，所以现在基本没人用这两个容器，但是面试经常问这两个容器里面的数据结构等内容 后来，出现了HashMap，此容器完全不加锁，是用的最多的容器 但是完全不加锁未免不完善，所以java提供了如下方式，将HashMap变为加锁的 //通过Collections.synchronizedMap(HashMap)方法，将其变为加锁Map集合，其中泛型随意，UUID只是举例。static Map<UUID, UUID> m = Collections.synchronizedMap(new HashMap<UUID, UUID>()); 通过阅读源码发现，上面方法将HashMap变为加锁，也是使用Synchronized，只是锁的内容更细，但并不比HashTable效率高多少 所以衍生除了新的容器ConcurrentHashMap ConcurrentHashMap 此容器，插入效率不如上面的，因为它做了各种判断和CAS，但是差距不是特别大 读取效率很高，100个线程同时访问，每个线程读取一百万次实测 Hashtable 39s ，SynchronizedHashMap 38s ，ConcurrentHashMap 1.7s 前两个将近40秒，ConcurrentHashMap只需要不到2s，由此可见此容器读取效率极高 2、为什么推荐使用Queue来做高并发 为什么推荐Queue（队列） Queue接口提供了很多针对多线程非常友好的API（offer ，peek和poll，其中BlockingQueue还添加了put和take可以阻塞），可以说专门为多线程高并发而创造的接口，所以一般我们使用Queue而不用List 以下代码分别使用链表LinkList和ConcurrentQueue，对比一下速度 LinkList用了5s多，ConcurrentQueue几乎瞬间完成 Concurrent接口就是专为多线程设计，多线程设计要多考虑Queue(高并发用)的使用，少使用List / 有N张火车票，每张票都有一个编号 同时有10个窗口对外售票 请写一个模拟程序 分析下面的程序可能会产生哪些问题？ 重复销售？超量销售？ 使用Vector或者Collections.synchronizedXXX 分析一下，这样能解决问题吗？ 就算操作A和B都是同步的，但A和B组成的复合操作也未必是同步的，仍然需要自己进行同步 就像这个程序，判断size和进行remove必须是一整个的原子操作 @author 马士兵/import java.util.LinkedList;import java.util.List;import java.util.concurrent.TimeUnit;public class TicketSeller3 {static List<String> tickets = new LinkedList<>();static {for(int i=0; i<1000; i++) tickets.add("票 编号：" + i);}public static void main(String[] args) {for(int i=0; i<10; i++) {new Thread(()->{while(true) {synchronized(tickets) {if(tickets.size() <= 0) break;try {TimeUnit.MILLISECONDS.sleep(10);} catch (InterruptedException e) {e.printStackTrace();}System.out.println("销售了--" + tickets.remove(0));} }}).start();} }} 队列 import java.util.Queue;import java.util.concurrent.ConcurrentLinkedQueue;public class TicketSeller4 {static Queue<String> tickets = new ConcurrentLinkedQueue<>();static {for(int i=0; i<1000; i++) tickets.add("票 编号：" + i);}public static void main(String[] args) {for(int i=0; i<10; i++) {new Thread(()->{while(true) {String s = tickets.poll();if(s == null) break;else System.out.println("销售了--" + s);} }).start();} }} 3、多线程常用容器 1、ConcurrentHashMap(无序)和ConcurrentSkipListMap(有序，链表，使用跳表数据结构，让查询更快) 跳表：http://blog.csdn.net/sunxianghuang/article/details/52221913 import java.util.;import java.util.concurrent.ConcurrentHashMap;import java.util.concurrent.ConcurrentSkipListMap;import java.util.concurrent.CountDownLatch;public class T01_ConcurrentMap {public static void main(String[] args) {Map<String, String> map = new ConcurrentHashMap<>();//Map<String, String> map = new ConcurrentSkipListMap<>(); //高并发并且排序//Map<String, String> map = new Hashtable<>();//Map<String, String> map = new HashMap<>(); //Collections.synchronizedXXX//TreeMapRandom r = new Random();Thread[] ths = new Thread[100];CountDownLatch latch = new CountDownLatch(ths.length);long start = System.currentTimeMillis();for(int i=0; i<ths.length; i++) {ths[i] = new Thread(()->{for(int j=0; j<10000; j++) map.put("a" + r.nextInt(100000), "a" + r.nextInt(100000));latch.countDown();});}Arrays.asList(ths).forEach(t->t.start());try {latch.await();} catch (InterruptedException e) {e.printStackTrace();}long end = System.currentTimeMillis();System.out.println(end - start);System.out.println(map.size());} } 2、CopyOnWriteList（写时复制）和CopyOnWriteSet 适用于，高并发是，读的多，写的少的情况 当我们写的时候，将容器复制，让写线程去复制的线程写（写的时候加锁） 而读线程依旧去读旧的(读的时候不加锁) 当写完，将对象指向复制后的已经写完的容器，原来容器销毁 大大提高读的效率 / 写时复制容器 copy on write 多线程环境下，写时效率低，读时效率高 适合写少读多的环境 @author 马士兵/import java.util.ArrayList;import java.util.Arrays;import java.util.List;import java.util.Random;import java.util.Vector;import java.util.concurrent.CopyOnWriteArrayList;public class T02_CopyOnWriteList {public static void main(String[] args) {List<String> lists = //new ArrayList<>(); //这个会出并发问题！//new Vector();new CopyOnWriteArrayList<>();Random r = new Random();Thread[] ths = new Thread[100];for(int i=0; i<ths.length; i++) {Runnable task = new Runnable() {@Overridepublic void run() {for(int i=0; i<1000; i++) lists.add("a" + r.nextInt(10000));} };ths[i] = new Thread(task);}runAndComputeTime(ths);System.out.println(lists.size());}static void runAndComputeTime(Thread[] ths) {long s1 = System.currentTimeMillis();Arrays.asList(ths).forEach(t->t.start());Arrays.asList(ths).forEach(t->{try {t.join();} catch (InterruptedException e) {e.printStackTrace();} });long s2 = System.currentTimeMillis();System.out.println(s2 - s1);} } 3、synchronizedList和ConcurrentLinkedQueue package com.mashibing.juc.c_025;import java.util.ArrayList;import java.util.Collections;import java.util.List;import java.util.Queue;import java.util.concurrent.ConcurrentLinkedQueue;public class T04_ConcurrentQueue {public static void main(String[] args) {List<String> strsList = new ArrayList<>();List<String> strsSync = Collections.synchronizedList(strsList);//加锁ListQueue<String> strs = new ConcurrentLinkedQueue<>();//Concurrent链表队列，就是读快for(int i=0; i<10; i++) {strs.offer("a" + i); //add添加，但是不同点是，此方法会返回一个布尔值}System.out.println(strs);System.out.println(strs.size());System.out.println(strs.poll());//取出，取完后将元素去除System.out.println(strs.size());System.out.println(strs.peek());//取出，但是不会将元素从队列删除System.out.println(strs.size());//双端队列Deque} } 4、LinkedBlockingQueue 链表阻塞队列（无界链表，可以一直装东西，直到内存满（其实，也不是无限，其长度Integer.MaxValue就是上限，毕竟最大就这么大）） 主要体现在put和take方法，put添加的时候，如果队列满了，就阻塞当前线程，直到队列有空位，继续插入。take方法取的时候，如果没有值，就阻塞，等有值了，立马去取 import java.util.Random;import java.util.concurrent.BlockingQueue;import java.util.concurrent.LinkedBlockingQueue;import java.util.concurrent.TimeUnit;public class T05_LinkedBlockingQueue {static BlockingQueue<String> strs = new LinkedBlockingQueue<>();static Random r = new Random();public static void main(String[] args) {new Thread(() -> {for (int i = 0; i < 100; i++) {try {strs.put("a" + i); //如果满了，当前线程就会等待（实现阻塞），等多会有空位，将值插入TimeUnit.MILLISECONDS.sleep(r.nextInt(1000));} catch (InterruptedException e) {e.printStackTrace();} }}, "p1").start();for (int i = 0; i < 5; i++) {new Thread(() -> {for (;;) {try {System.out.println(Thread.currentThread().getName() + " take -" + strs.take()); //取内容，如果空了，当前线程就会等待（实现阻塞）} catch (InterruptedException e) {e.printStackTrace();} }}, "c" + i).start();} }} 5、ArrayBlockingQueue 有界阻塞队列（因为Array需要指定长度） import java.util.Random;import java.util.concurrent.ArrayBlockingQueue;import java.util.concurrent.BlockingQueue;import java.util.concurrent.TimeUnit;public class T06_ArrayBlockingQueue {static BlockingQueue<String> strs = new ArrayBlockingQueue<>(10);static Random r = new Random();public static void main(String[] args) throws InterruptedException {for (int i = 0; i < 10; i++) {strs.put("a" + i);}//strs.put("aaa"); //满了就会等待，程序阻塞//strs.add("aaa");//strs.offer("aaa");strs.offer("aaa", 1, TimeUnit.SECONDS);System.out.println(strs);} } 6、特殊的阻塞队列1：DelayQueue 延时队列（按时间进行调度，就是隔多长时间运行，谁隔的少，谁先） 以下例子中，我们添加线程到队列顺序为t12345，正常情况下，会按照顺序运行，但是这里有了延时时间，也就是时间越短，越先执行 步骤很简单，拿到延时队列 指定构造方法 继承 implements Delayed 重写 compareTo和getDelay import java.util.Calendar;import java.util.Random;import java.util.concurrent.BlockingQueue;import java.util.concurrent.DelayQueue;import java.util.concurrent.Delayed;import java.util.concurrent.TimeUnit;public class T07_DelayQueue {static BlockingQueue<MyTask> tasks = new DelayQueue<>();static Random r = new Random();static class MyTask implements Delayed {String name;long runningTime;MyTask(String name, long rt) {this.name = name;this.runningTime = rt;}@Overridepublic int compareTo(Delayed o) {if(this.getDelay(TimeUnit.MILLISECONDS) < o.getDelay(TimeUnit.MILLISECONDS))return -1;else if(this.getDelay(TimeUnit.MILLISECONDS) > o.getDelay(TimeUnit.MILLISECONDS)) return 1;else return 0;}@Overridepublic long getDelay(TimeUnit unit) {return unit.convert(runningTime - System.currentTimeMillis(), TimeUnit.MILLISECONDS);}@Overridepublic String toString() {return name + " " + runningTime;} }public static void main(String[] args) throws InterruptedException {long now = System.currentTimeMillis();MyTask t1 = new MyTask("t1", now + 1000);MyTask t2 = new MyTask("t2", now + 2000);MyTask t3 = new MyTask("t3", now + 1500);MyTask t4 = new MyTask("t4", now + 2500);MyTask t5 = new MyTask("t5", now + 500);tasks.put(t1);tasks.put(t2);tasks.put(t3);tasks.put(t4);tasks.put(t5);System.out.println(tasks);for(int i=0; i<5; i++) {System.out.println(tasks.take());//获取的是toString方法返回值} }} 7、特殊的阻塞队列2：PriorityQueque 优先队列（二叉树算法，就是排序） import java.util.PriorityQueue;public class T07_01_PriorityQueque {public static void main(String[] args) {PriorityQueue<String> q = new PriorityQueue<>();q.add("c");q.add("e");q.add("a");q.add("d");q.add("z");for (int i = 0; i < 5; i++) {System.out.println(q.poll());} }} 8、特殊的阻塞队列3：SynchronusQueue 同步队列(线程池用处非常大) 此队列容量为0，当插入元素时，必须同时有个线程往外取 就是说，当你往这个队列里面插入一个元素，它就拿着这个元素站着(阻塞)，直到有个取元素的线程来，它就把元素交给它 就是用来同步数据的，也就是线程间交互数据用的一个特殊队列 package com.mashibing.juc.c_025;import java.util.concurrent.BlockingQueue;import java.util.concurrent.SynchronousQueue;public class T08_SynchronusQueue { //容量为0public static void main(String[] args) throws InterruptedException {BlockingQueue<String> strs = new SynchronousQueue<>();new Thread(()->{//这个线程就是消费者，来取值try {System.out.println(strs.take());//和同步队列要值} catch (InterruptedException e) {e.printStackTrace();} }).start();strs.put("aaa"); //阻塞等待消费者消费，就拿着aaa站着，等线程来取//strs.put("bbb");//strs.add("aaa");System.out.println(strs.size());} } 9、特殊的阻塞队列4：TransferQueue 传递队列 此队列加入了一个方法transfer()用来向队列添加元素 但是和put()方法不同的是，put添加完元素就走了 而这个方法，添加完自己就阻塞了，直到有人将这个元素取走，它才继续工作(省去我们手动阻塞) import java.util.concurrent.LinkedTransferQueue;public class T09_TransferQueue {public static void main(String[] args) throws InterruptedException {LinkedTransferQueue<String> strs = new LinkedTransferQueue<>();new Thread(() -> {try {System.out.println(strs.take());} catch (InterruptedException e) {e.printStackTrace();} }).start();strs.transfer("aaa");//放东西到队列，同时阻塞等待消费者线程，取走元素//strs.put("aaa");//如果用put就和普通队列一样，放完东西就走了/new Thread(() -> {try {System.out.println(strs.take());} catch (InterruptedException e) {e.printStackTrace();} }).start();/} } 3、线程池 线程池 由于单独创建线程，十分影响效率，而且无法对线程集中管理，一旦疏落，可能线程无限执行，浪费资源 线程池就是一个存储线程的游泳池，而每个线程就是池子里面的赛道 池子里的线程不执行任何任务，只是提供一个资源 而谁提交了任务，比如我想来游泳，那么池子就给你一个赛道，让你游泳 比如它想练憋气，那么给它一个赛道练憋气 当他们用完，走了，那么后面其它人再过来继续用 这就是线程池，始终只有这几个线程，不做实现，而是借用这几个线程的用户，自己掌控用这些线程资源做什么（提交任务给线程,线程空闲就帮他们完成任务） 线程池的两种类型（两类，不是两个） ThreadPoolExecutor（简称TPE） ForkJoinPool（分解汇总任务(将任务细化，最后汇总结果)，少量线程执行多个任务（子任务，TPE做不到先执行子任务），CPU密集型） Executors（注意这后面有s） 它可以说是线程池工厂类，我们一般通过它创建线程池，并且它为我们封装了线程 1、常用类 Executor ExecutorService 扩展了execute方法，具有一个返回值 规定了异步执行机制，提供了一些执行器方法，比如shutdown()关闭等 但是它不知道执行器中的线程何时执行完 Callable 对Runnable进行了扩展,实现Callable的调用，可以有返回值，表示线程的状态 但是无法返回线程执行结果 Future 获得未来线程执行结果 由此，我们可以得知线程池基本的一个使用步骤 其中service.submit（）:为异步提交，也就是说，主线程该干嘛干嘛，我是异步执行的，和同步不一样（当前线程执行完，主线程才能继续执行，叫同步） futuer.get():获取结果集结果，此时因为异步，主线程执行到这里，结果集可能还没封装好，所以此时如果没有值，就阻塞，直到结果集出来 public static void main(String[] args) throws ExecutionException, InterruptedException {Callable<String> c = new Callable() {@Overridepublic String call() throws Exception {return "Hello Callable";} };ExecutorService service = Executors.newCachedThreadPool();Future<String> future = service.submit(c); //异步System.out.println(future.get());//阻塞service.shutdown();} 2、FutureTask 可充当任务的结果集 上面我们介绍Future是用来得到任务的执行结果的 而FutureTask，可以当做一个任务用，并且返回任务的结果，也就是可以跑线程，然后还可以得到线程结果 public static void main(String[] args) throws InterruptedException, ExecutionException {FutureTask<Integer> task = new FutureTask<>(()->{TimeUnit.MILLISECONDS.sleep(500);return 1000;}); //new Callable () { Integer call();}new Thread(task).start();System.out.println(task.get()); //阻塞} 3、CompletableFuture 非常灵活的任务结果集 一个非常灵活的结果集 他可以将很多执行不同任务的线程的结果进行汇总 比如一个网站，它可以启动多个线程去各大电商网站，比如淘宝，京东，收集某些或某一个商品的价格 最后，将获取的数据进行整合封装 最终，客户就可以通过此网站，获取某类商品在各网站的价格信息 / 假设你能够提供一个服务 这个服务查询各大电商网站同一类产品的价格并汇总展示 @author 马士兵 http://mashibing.com/import java.io.IOException;import java.util.Random;import java.util.concurrent.CompletableFuture;import java.util.concurrent.ExecutionException;import java.util.concurrent.TimeUnit;public class T06_01_CompletableFuture {public static void main(String[] args) throws ExecutionException, InterruptedException {long start, end;/start = System.currentTimeMillis();priceOfTM();priceOfTB();priceOfJD();end = System.currentTimeMillis();System.out.println("use serial method call! " + (end - start));/start = System.currentTimeMillis();CompletableFuture<Double> futureTM = CompletableFuture.supplyAsync(()->priceOfTM());CompletableFuture<Double> futureTB = CompletableFuture.supplyAsync(()->priceOfTB());CompletableFuture<Double> futureJD = CompletableFuture.supplyAsync(()->priceOfJD());CompletableFuture.allOf(futureTM, futureTB, futureJD).join();//当所有结果集都获取到，才汇总阻塞CompletableFuture.supplyAsync(()->priceOfTM()).thenApply(String::valueOf).thenApply(str-> "price " + str).thenAccept(System.out::println);end = System.currentTimeMillis();System.out.println("use completable future! " + (end - start));try {System.in.read();} catch (IOException e) {e.printStackTrace();} }private static double priceOfTM() {delay();return 1.00;}private static double priceOfTB() {delay();return 2.00;}private static double priceOfJD() {delay();return 3.00;}/private static double priceOfAmazon() {delay();throw new RuntimeException("product not exist!");}/private static void delay() {int time = new Random().nextInt(500);try {TimeUnit.MILLISECONDS.sleep(time);} catch (InterruptedException e) {e.printStackTrace();}System.out.printf("After %s sleep!\n", time);} } 4、TPE型线程池1：ThreadPoolExecutor 原理及其参数 线程池由两个集合组成，一个集合存储线程，一个集合存储任务 存储线程：可以规定大小，最多可以有多少个，以及指定核心线程数量（不会被回收） 任务队列：存储任务 细节：初始线程池没有线程，当有一个任务来，线程池起一个线程，又有一个任务来，再起一个线程，直到达到核心线程数量 核心线程数量达到时，新来的任务将存储到任务队列中等待核心线程处理完成，直到任务队列也满了 当任务队列满了，此时再次启动一个线程（非核心线程，一旦空闲，达到指定时间将会消失），直到达到线程最大数量 当线程容器和任务容器都满了，又来了线程，将会执行拒绝策略 上面的细节涉及的所有步骤内容，均由创建线程池的参数执行 下面是ThreadPoolExecutor构造方法参数的源码注释 / 用给定的初始值，创建一个新的线程池 @param corePoolSize 核心线程数量 @param maximumPoolSize 最大线程数量 @param keepAliveTime 当线程数大于核心线程数量时，空闲的线程可生存的时间 @param unit 时间单位 @param workQueue 任务队列，只能包含由execute提交的Runnable任务 @param threadFactory 工厂，用于创建线程给线程池调度的工厂，可以自定义 @param handler 拒绝策略(可以自定义，JDK默认提供4种)，当线程边界和队列容量已经满了，新来线程被阻塞时使用的处理程序/public ThreadPoolExecutor(int corePoolSize,int maximumPoolSize,long keepAliveTime,TimeUnit unit,BlockingQueue<Runnable> workQueue,ThreadFactory threadFactory,RejectedExecutionHandler handler) JDK提供的4种拒绝策略，不常用，一般都是自己定义拒绝策略 Abort：抛异常 Discard：扔掉，不抛异常 DiscardOldest：扔掉排队时间最久的（将队列中排队时间最久的扔掉，然后让新来的进来） CallerRuns：调用者处理任务（谁通过execute方法提交任务，谁处理） ThreadPoolExecutor继承关系 继承关系：ThreadPoolExecutor->AbstractExectorService类->ExectorService接口->Exector接口 Executors（注意这后面有s） 它可以说是线程池工厂类，我们一般通过它创建线程池，并且它为我们封装了线程 看看下面创建线程池，哪里用到了它 使用实例 import java.io.IOException;import java.util.concurrent.;public class T05_00_HelloThreadPool {static class Task implements Runnable {private int i;public Task(int i) {this.i = i;}@Overridepublic void run() {System.out.println(Thread.currentThread().getName() + " Task " + i);try {System.in.read();} catch (IOException e) {e.printStackTrace();} }@Overridepublic String toString() {return "Task{" +"i=" + i +'}';} }public static void main(String[] args) {ThreadPoolExecutor tpe = new ThreadPoolExecutor(2, 4,60, TimeUnit.SECONDS,new ArrayBlockingQueue<Runnable>(4),Executors.defaultThreadFactory(),new ThreadPoolExecutor.CallerRunsPolicy());//创建线程池，核心2个，最大4个，空闲线程存活时间60s，任务队列容量4，使用默认线程工程，创建线程。拒绝策略是JDK提供的for (int i = 0; i < 8; i++) {tpe.execute(new Task(i));//供提交8次任务}System.out.println(tpe.getQueue());//查看任务队列tpe.execute(new Task(100));//提交新的任务System.out.println(tpe.getQueue());tpe.shutdown();//关闭线程池} } 5、TPE型线程池2：SingleThreadPool 单例线程池(只有一个线程) 为什么有单例线程池 有任务队列，有线程池管理机制 Executors（注意这后面有s） 它可以说是线程池工厂类，我们一般通过它创建线程池，并且它为我们封装了线程 看看下面哪里用到了它 /创建单例线程池，扔5个任务进去，查看输出结果，看看有几个线程执行任务/import java.util.concurrent.ExecutorService;import java.util.concurrent.Executors;public class T07_SingleThreadPool {public static void main(String[] args) {ExecutorService service = Executors.newSingleThreadExecutor();for(int i=0; i<5; i++) {final int j = i;service.execute(()->{System.out.println(j + " " + Thread.currentThread().getName());});} }} 6、TPE型线程池3：CachedPool 缓存，存储线程池 此线程池没有核心线程，来一个任务启动一个线程（最多Integer.MaxValue，不会放在任务队列，因为任务队列容量为0），每个线程空闲后，只能活60s 实例 import java.util.concurrent.ExecutorService;import java.util.concurrent.Executors;public class T07_SingleThreadPool {public static void main(String[] args) {ExecutorService service = Executors.newSingleThreadExecutor();//通过Executors获取池子for(int i=0; i<5; i++) {final int j = i;service.execute(()->{//提交任务System.out.println(j + " " + Thread.currentThread().getName());});}service.shutdown();} } 7、TPE型线程池4：FixedThreadPool 固定线程池 此线次池，用于创建一个固定线程数量的线程池，不会回收 实例 import java.util.ArrayList;import java.util.List;import java.util.concurrent.Callable;import java.util.concurrent.ExecutionException;import java.util.concurrent.ExecutorService;import java.util.concurrent.Executors;import java.util.concurrent.Future;public class T09_FixedThreadPool {public static void main(String[] args) throws InterruptedException, ExecutionException {//并发执行long start = System.currentTimeMillis();getPrime(1, 200000); long end = System.currentTimeMillis();System.out.println(end - start);//输出并发执行耗费时间final int cpuCoreNum = 4;//并行执行ExecutorService service = Executors.newFixedThreadPool(cpuCoreNum);MyTask t1 = new MyTask(1, 80000); //1-5 5-10 10-15 15-20MyTask t2 = new MyTask(80001, 130000);MyTask t3 = new MyTask(130001, 170000);MyTask t4 = new MyTask(170001, 200000);Future<List<Integer>> f1 = service.submit(t1);Future<List<Integer>> f2 = service.submit(t2);Future<List<Integer>> f3 = service.submit(t3);Future<List<Integer>> f4 = service.submit(t4);start = System.currentTimeMillis();f1.get();f2.get();f3.get();f4.get();end = System.currentTimeMillis();System.out.println(end - start);//输出并行耗费时间}static class MyTask implements Callable<List<Integer>> {int startPos, endPos;MyTask(int s, int e) {this.startPos = s;this.endPos = e;}@Overridepublic List<Integer> call() throws Exception {List<Integer> r = getPrime(startPos, endPos);return r;} }static boolean isPrime(int num) {for(int i=2; i<=num/2; i++) {if(num % i == 0) return false;}return true;}static List<Integer> getPrime(int start, int end) {List<Integer> results = new ArrayList<>();for(int i=start; i<=end; i++) {if(isPrime(i)) results.add(i);}return results;} } 8、TPE型线程池5：ScheduledPool 预定，延时线程池 根据延时时间（隔多长时间后运行），排序，哪个线程先执行,用户只需要指定核心线程数量 此线程池返回的池对象，和提交任务方法都不一样，比较涉及到时间 import java.util.Random;import java.util.concurrent.Executors;import java.util.concurrent.ScheduledExecutorService;import java.util.concurrent.TimeUnit;public class T10_ScheduledPool {public static void main(String[] args) {ScheduledExecutorService service = Executors.newScheduledThreadPool(4);service.scheduleAtFixedRate(()->{//提交延时任务try {TimeUnit.MILLISECONDS.sleep(new Random().nextInt(1000));} catch (InterruptedException e) {e.printStackTrace();}System.out.println(Thread.currentThread().getName());}, 0, 500, TimeUnit.MILLISECONDS);//指定延时时间和单位，第一个任务延时0毫秒，之后的任务，延时500毫秒} } 9、手写拒绝策略小例子 import java.util.concurrent.;public class T14_MyRejectedHandler {public static void main(String[] args) {ExecutorService service = new ThreadPoolExecutor(4, 4,0, TimeUnit.SECONDS, new ArrayBlockingQueue<>(6),Executors.defaultThreadFactory(),new MyHandler());//将手写拒绝策略传入}static class MyHandler implements RejectedExecutionHandler {//1、继承RejectedExecutionHandler@Overridepublic void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {//2、重写方法//log("r rejected")//伪代码，表示通过log4j.log()报一下日志，拒绝的时间，线程名//save r kafka mysql redis//可以尝试保存队列//try 3 times //可以尝试几次，比如3次，重新去抢队列，3次还不行就丢弃if(executor.getQueue().size() < 10000) {//尝试条件，如果size>10000了,就执行拒绝策略//try put again();//如果小于10000，尝试将其放到队列中} }} } 10、ForkJoinPool线程池1：ForkJoinPool 前面我们讲过线程分为两大类，TPE和FJP ForkJoinPool（分解汇总任务(将任务细化，最后汇总结果)，少量线程执行多个任务（子任务，TPE做不到先执行子任务），CPU密集型） 适合将大任务切分成多个小任务运行 两个方法，fork()：分子任务，将子任务分配到线程池中 join()：当前任务的计算结果，如果有子任务，等子任务结果返回后再汇总 下面实例实现，一百万个随机数求和，由两种方法实现，一种ForkJoinPool分任务并行，一种使用单线程做 import java.io.IOException;import java.util.Arrays;import java.util.Random;import java.util.concurrent.ForkJoinPool;import java.util.concurrent.RecursiveAction;import java.util.concurrent.RecursiveTask;public class T12_ForkJoinPool {//1000000个随机数求和static int[] nums = new int[1000000];//一堆数static final int MAX_NUM = 50000;//分任务时，每个任务的操作量不能多于50000个，否则就继续细分static Random r = new Random();//使用随机数将数组初始化static {for(int i=0; i<nums.length; i++) {nums[i] = r.nextInt(100);}System.out.println("---" + Arrays.stream(nums).sum()); //stream api 单线程就这么做，一个一个加}//分任务，需要继承，可以继承RecursiveAction(不需要返回值，一般用在不需要返回值的场景)或//RecursiveTask(需要返回值，我们用这个，因为我们需要最后获取求和结果)两个更好实现的类，//他俩继承与ForkJoinTaskstatic class AddTaskRet extends RecursiveTask<Long> {private static final long serialVersionUID = 1L;int start, end;AddTaskRet(int s, int e) {start = s;end = e;}@Overrideprotected Long compute() {if(end-start <= MAX_NUM) {//如果任务操作数小于规定的最大操作数，就进行运算，long sum = 0L;for(int i=start; i<end; i++) sum += nums[i];return sum;//返回结果} //如果分配的操作数大于规定，就继续细分（简单的重中点分，两半）int middle = start + (end-start)/2;//获取中间值AddTaskRet subTask1 = new AddTaskRet(start, middle);//传入起始值和中间值，表示一个子任务AddTaskRet subTask2 = new AddTaskRet(middle, end);//中间值和结尾值，表示一个子任务subTask1.fork();//分任务subTask2.fork();//分任务return subTask1.join() + subTask2.join();//最后返回结果汇总} }public static void main(String[] args) throws IOException {/ForkJoinPool fjp = new ForkJoinPool();AddTask task = new AddTask(0, nums.length);fjp.execute(task);/ForkJoinPool fjp = new ForkJoinPool();//创建线程池AddTaskRet task = new AddTaskRet(0, nums.length);//创建任务fjp.execute(task);//传入任务long result = task.join();//返回汇总结果System.out.println(result);//System.in.read();} } 11、ForkJoinPool线程池2：WorkStealingPool 任务偷取线程池 原来的线程池，都是有一个任务队列，而这个不同，它给每个线程都分配了一个任务队列 当某一个线程的任务队列没有任务，并且自己空闲，它就去其它线程的任务队列中偷任务，所以叫任务偷取线程池 细节：当线程自己从自己的任务队列拿任务时，不需要加锁，但是偷任务时，因为有两个线程，可能发生同步问题，需要加锁 此线程继承FJP 实例 import java.io.IOException;import java.util.concurrent.ExecutorService;import java.util.concurrent.Executors;import java.util.concurrent.TimeUnit;public class T11_WorkStealingPool {public static void main(String[] args) throws IOException {ExecutorService service = Executors.newWorkStealingPool();System.out.println(Runtime.getRuntime().availableProcessors());service.execute(new R(1000));service.execute(new R(2000));service.execute(new R(2000));service.execute(new R(2000)); //daemonservice.execute(new R(2000));//由于产生的是精灵线程（守护线程、后台线程），主线程不阻塞的话，看不到输出System.in.read(); }static class R implements Runnable {int time;R(int t) {this.time = t;}@Overridepublic void run() {try {TimeUnit.MILLISECONDS.sleep(time);} catch (InterruptedException e) {e.printStackTrace();}System.out.println(time + " " + Thread.currentThread().getName());} }} 12、流式API：ParallelStreamAPI 不懂的请参考：https://blog.csdn.net/grd_java/article/details/110265219 实例 import java.util.ArrayList;import java.util.List;import java.util.Random;public class T13_ParallelStreamAPI {public static void main(String[] args) {List<Integer> nums = new ArrayList<>();Random r = new Random();for(int i=0; i<10000; i++) nums.add(1000000 + r.nextInt(1000000));//System.out.println(nums);long start = System.currentTimeMillis();nums.forEach(v->isPrime(v));long end = System.currentTimeMillis();System.out.println(end - start);//使用parallel stream apistart = System.currentTimeMillis();nums.parallelStream().forEach(T13_ParallelStreamAPI::isPrime);//并行流，将任务切分成子任务执行end = System.currentTimeMillis();System.out.println(end - start);}static boolean isPrime(int num) {for(int i=2; i<=num/2; i++) {if(num % i == 0) return false;}return true;} } 13、总结 总结 Callable相当于一Runnable但是它有返回值 Future：存储执行完产生的结果 FutureTask 相当于Future+Runnable，既可以执行任务，又能获取任务执行的Future结果 CompletableFuture 可以多任务异步，并对多任务控制，整合任务结果，细化完美，比如可以一个任务完成就可以整合结果，也可以所有任务完成才整合结果 4、ThreadPoolExecutor源码解析 依然只讲重点，实际还需要大家按照上篇博客中看源码的方式来看 1、常用变量的解释 // 1. ctl，可以看做一个int类型的数字，高3位表示线程池状态，低29位表示worker数量private final AtomicInteger ctl = new AtomicInteger(ctlOf(RUNNING, 0));// 2. COUNT_BITS，Integer.SIZE为32，所以COUNT_BITS为29private static final int COUNT_BITS = Integer.SIZE - 3;// 3. CAPACITY，线程池允许的最大线程数。1左移29位，然后减1，即为 2^29 - 1private static final int CAPACITY = (1 << COUNT_BITS) - 1;// runState is stored in the high-order bits// 4. 线程池有5种状态，按大小排序如下：RUNNING < SHUTDOWN < STOP < TIDYING < TERMINATEDprivate static final int RUNNING = -1 << COUNT_BITS;private static final int SHUTDOWN = 0 << COUNT_BITS;private static final int STOP = 1 << COUNT_BITS;private static final int TIDYING = 2 << COUNT_BITS;private static final int TERMINATED = 3 << COUNT_BITS;// Packing and unpacking ctl// 5. runStateOf()，获取线程池状态，通过按位与操作，低29位将全部变成0private static int runStateOf(int c) { return c & ~CAPACITY; }// 6. workerCountOf()，获取线程池worker数量，通过按位与操作，高3位将全部变成0private static int workerCountOf(int c) { return c & CAPACITY; }// 7. ctlOf()，根据线程池状态和线程池worker数量，生成ctl值private static int ctlOf(int rs, int wc) { return rs | wc; }/ Bit field accessors that don't require unpacking ctl. These depend on the bit layout and on workerCount being never negative./// 8. runStateLessThan()，线程池状态小于xxprivate static boolean runStateLessThan(int c, int s) {return c < s;}// 9. runStateAtLeast()，线程池状态大于等于xxprivate static boolean runStateAtLeast(int c, int s) {return c >= s;} 2、构造方法 public ThreadPoolExecutor(int corePoolSize,int maximumPoolSize,long keepAliveTime,TimeUnit unit,BlockingQueue<Runnable> workQueue,ThreadFactory threadFactory,RejectedExecutionHandler handler) {// 基本类型参数校验if (corePoolSize < 0 ||maximumPoolSize <= 0 ||maximumPoolSize < corePoolSize ||keepAliveTime < 0)throw new IllegalArgumentException();// 空指针校验if (workQueue == null || threadFactory == null || handler == null)throw new NullPointerException();this.corePoolSize = corePoolSize;this.maximumPoolSize = maximumPoolSize;this.workQueue = workQueue;// 根据传入参数unit和keepAliveTime，将存活时间转换为纳秒存到变量keepAliveTime 中this.keepAliveTime = unit.toNanos(keepAliveTime);this.threadFactory = threadFactory;this.handler = handler;} 3、提交执行task的过程 public void execute(Runnable command) {if (command == null)throw new NullPointerException();/ Proceed in 3 steps: 1. If fewer than corePoolSize threads are running, try to start a new thread with the given command as its first task. The call to addWorker atomically checks runState and workerCount, and so prevents false alarms that would add threads when it shouldn't, by returning false. 2. If a task can be successfully queued, then we still need to double-check whether we should have added a thread (because existing ones died since last checking) or that the pool shut down since entry into this method. So we recheck state and if necessary roll back the enqueuing if stopped, or start a new thread if there are none. 3. If we cannot queue task, then we try to add a new thread. If it fails, we know we are shut down or saturated and so reject the task./int c = ctl.get();// worker数量比核心线程数小，直接创建worker执行任务if (workerCountOf(c) < corePoolSize) {if (addWorker(command, true))return;c = ctl.get();}// worker数量超过核心线程数，任务直接进入队列if (isRunning(c) && workQueue.offer(command)) {int recheck = ctl.get();// 线程池状态不是RUNNING状态，说明执行过shutdown命令，需要对新加入的任务执行reject()操作。// 这儿为什么需要recheck，是因为任务入队列前后，线程池的状态可能会发生变化。if (! isRunning(recheck) && remove(command))reject(command);// 这儿为什么需要判断0值，主要是在线程池构造方法中，核心线程数允许为0else if (workerCountOf(recheck) == 0)addWorker(null, false);}// 如果线程池不是运行状态，或者任务进入队列失败，则尝试创建worker执行任务。// 这儿有3点需要注意：// 1. 线程池不是运行状态时，addWorker内部会判断线程池状态// 2. addWorker第2个参数表示是否创建核心线程// 3. addWorker返回false，则说明任务执行失败，需要执行reject操作else if (!addWorker(command, false))reject(command);} 4、addworker源码解析 private boolean addWorker(Runnable firstTask, boolean core) {retry:// 外层自旋for (;;) {int c = ctl.get();int rs = runStateOf(c);// 这个条件写得比较难懂，我对其进行了调整，和下面的条件等价// (rs > SHUTDOWN) || // (rs == SHUTDOWN && firstTask != null) || // (rs == SHUTDOWN && workQueue.isEmpty())// 1. 线程池状态大于SHUTDOWN时，直接返回false// 2. 线程池状态等于SHUTDOWN，且firstTask不为null，直接返回false// 3. 线程池状态等于SHUTDOWN，且队列为空，直接返回false// Check if queue empty only if necessary.if (rs >= SHUTDOWN &&! (rs == SHUTDOWN &&firstTask == null &&! workQueue.isEmpty()))return false;// 内层自旋for (;;) {int wc = workerCountOf(c);// worker数量超过容量，直接返回falseif (wc >= CAPACITY ||wc >= (core ? corePoolSize : maximumPoolSize))return false;// 使用CAS的方式增加worker数量。// 若增加成功，则直接跳出外层循环进入到第二部分if (compareAndIncrementWorkerCount(c))break retry;c = ctl.get(); // Re-read ctl// 线程池状态发生变化，对外层循环进行自旋if (runStateOf(c) != rs)continue retry;// 其他情况，直接内层循环进行自旋即可// else CAS failed due to workerCount change; retry inner loop} }boolean workerStarted = false;boolean workerAdded = false;Worker w = null;try {w = new Worker(firstTask);final Thread t = w.thread;if (t != null) {final ReentrantLock mainLock = this.mainLock;// worker的添加必须是串行的，因此需要加锁mainLock.lock();try {// Recheck while holding lock.// Back out on ThreadFactory failure or if// shut down before lock acquired.// 这儿需要重新检查线程池状态int rs = runStateOf(ctl.get());if (rs < SHUTDOWN ||(rs == SHUTDOWN && firstTask == null)) {// worker已经调用过了start()方法，则不再创建workerif (t.isAlive()) // precheck that t is startablethrow new IllegalThreadStateException();// worker创建并添加到workers成功workers.add(w);// 更新largestPoolSize变量int s = workers.size();if (s > largestPoolSize)largestPoolSize = s;workerAdded = true;} } finally {mainLock.unlock();}// 启动worker线程if (workerAdded) {t.start();workerStarted = true;} }} finally {// worker线程启动失败，说明线程池状态发生了变化（关闭操作被执行），需要进行shutdown相关操作if (! workerStarted)addWorkerFailed(w);}return workerStarted;} 5、线程池worker任务单元 private final class Workerextends AbstractQueuedSynchronizerimplements Runnable{/ This class will never be serialized, but we provide a serialVersionUID to suppress a javac warning./private static final long serialVersionUID = 6138294804551838833L;/ Thread this worker is running in. Null if factory fails. /final Thread thread;/ Initial task to run. Possibly null. /Runnable firstTask;/ Per-thread task counter /volatile long completedTasks;/ Creates with given first task and thread from ThreadFactory. @param firstTask the first task (null if none)/Worker(Runnable firstTask) {setState(-1); // inhibit interrupts until runWorkerthis.firstTask = firstTask;// 这儿是Worker的关键所在，使用了线程工厂创建了一个线程。传入的参数为当前workerthis.thread = getThreadFactory().newThread(this);}/ Delegates main run loop to outer runWorker /public void run() {runWorker(this);}// 省略代码...} 6、核心线程执行逻辑-runworker final void runWorker(Worker w) {Thread wt = Thread.currentThread();Runnable task = w.firstTask;w.firstTask = null;// 调用unlock()是为了让外部可以中断w.unlock(); // allow interrupts// 这个变量用于判断是否进入过自旋（while循环）boolean completedAbruptly = true;try {// 这儿是自旋// 1. 如果firstTask不为null，则执行firstTask；// 2. 如果firstTask为null，则调用getTask()从队列获取任务。// 3. 阻塞队列的特性就是：当队列为空时，当前线程会被阻塞等待while (task != null || (task = getTask()) != null) {// 这儿对worker进行加锁，是为了达到下面的目的// 1. 降低锁范围，提升性能// 2. 保证每个worker执行的任务是串行的w.lock();// If pool is stopping, ensure thread is interrupted;// if not, ensure thread is not interrupted. This// requires a recheck in second case to deal with// shutdownNow race while clearing interrupt// 如果线程池正在停止，则对当前线程进行中断操作if ((runStateAtLeast(ctl.get(), STOP) ||(Thread.interrupted() &&runStateAtLeast(ctl.get(), STOP))) &&!wt.isInterrupted())wt.interrupt();// 执行任务，且在执行前后通过beforeExecute()和afterExecute()来扩展其功能。// 这两个方法在当前类里面为空实现。try {beforeExecute(wt, task);Throwable thrown = null;try {task.run();} catch (RuntimeException x) {thrown = x; throw x;} catch (Error x) {thrown = x; throw x;} catch (Throwable x) {thrown = x; throw new Error(x);} finally {afterExecute(task, thrown);} } finally {// 帮助gctask = null;// 已完成任务数加一 w.completedTasks++;w.unlock();} }completedAbruptly = false;} finally {// 自旋操作被退出，说明线程池正在结束processWorkerExit(w, completedAbruptly);} } 本篇文章为转载内容。原文链接：https://blog.csdn.net/grd_java/article/details/113116244。 该文由互联网用户投稿提供，文中观点代表作者本人意见，并不代表本站的立场。 作为信息平台，本站仅提供文章转载服务，并不拥有其所有权，也不对文章内容的真实性、准确性和合法性承担责任。 如发现本文存在侵权、违法、违规或事实不符的情况，请及时联系我们，我们将第一时间进行核实并删除相应内容。

... 微云下载 中英词汇索引表 本页内容 基本信息 作者：Jason Gregory （杰森.格雷戈瑞） 译者：Milo Yip（叶劲峰） 原书名：Game Engine Architecture 出版社：电子工业出版社 出版时间：2014-1-1 开本：16 页数：800 字数：1093400 ISBN：9787121222887 内容简介 《游戏引擎架构》同时涵盖游戏引擎软件开发的理论及实践，并对多方面的题目进行探讨。本书讨论到的概念及技巧实际应用于现实中的游戏工作室，如艺电及顽皮狗。虽然书中采用的例子通常依据一些专门的技术，但是讨论范围远超于某个引擎或API。文中的参考及引用也非常有用，可让读者继续深入游戏开发过程的任何特定方向。 《游戏引擎架构》为一个大学程度的游戏编程课程而编写，但也适合软件工程师、业余爱好者、自学游戏程序员，以及游戏产业的从业人员。通过阅读《游戏引擎架构》，资历较浅的游戏工程师可以巩固他们所学的游戏技术及引擎架构的知识，专注某一领域的资深程序员也能从本书更为全面的介绍中获益。 內容包括： 游戏开发中的大规模C++软件架构 游戏编程所需的数学 供调试、源代码控制及性能剖析的游戏开发工具 引擎基础系统、渲染、碰撞、物理、角色动画、游戏世界对象模型等引擎子系统 多平台游戏引擎 多处理器环境下的游戏编程 工作管道及游戏资产数据库 作者／译者简介 作者介绍：Jason Gregory在1994年开始任职专业软件工程师，自1999年3月开始在游戏产业中任职软件工程师。在圣迭哥Midway Home Entertainment公司开始游戏编程的他，为《疯狂飞行员（Freaky Flyers）》及《Crank the Weasel》开发PlayStation 2/Xbox上的动画系统。在2003年，他转到洛杉矶艺电，为《荣誉勋章：血战太平洋（Medal of Honor: Pacific Assault）》开发游戏引擎及游戏性技术，并在《荣誉勋章：空降神兵（Medal of Honor: Airborne）》中担任首席工程师。他现时是顽皮狗公司的通才程序员，为《神秘海域：德雷克船长的宝藏（Uncharted: Drake's Fortune）》及《神秘海域：纵横四海（Uncharted: Among Thieves）》开发引擎及游戏性软件。他也在南加州大学教授游戏技术的课程。 译者简介：叶劲峰（Milo Yip）从小自习编程，并爱好计算机图形学。上中学时兼职开发策略RPG《王子传奇》，该游戏在1995年于台湾发行。其后他获取了香港大学认知科学学士、香港中文大学系统工程及工程管理哲学硕士。毕业后在香港理工大学设计学院从事游戏引擎及相关技术的研发，职至项目主任。除发表学术文章外，也曾合著《DirectX9游戏编程实务》。2008年往上海育碧担任引擎工程师开发《美食从天而降（Cloudy with a Chance of Meatballs）》Xbox360/PS3/Wii/PC，2009年起于麻辣马开发《爱丽丝：疯狂回归（Alice: Madness Returns）》Xbox360/PS3/PC，2011年加入腾讯互动娱乐引擎技术中心担任专家工程师，所研发的技术已用于《斗战神》、《天涯明月刀》、《众神争霸》等项目中。 推荐序1 最初拿到《Game Engine Architecture》一书的英文版，是编辑侠少邮寄给我的打印版。他建议我接下翻译此书的合同。当时我正在杭州带领一个团队开发3D游戏引擎，我和我的同事都对这本书的内容颇有兴趣，两大本打印的英文书立刻在同事间传开。可惜那段时间个人精力顾及不来，把近千页的英文读物精读而后翻译成中文对个人的业余时间是个极大的挑战，不能担此翻译任务颇为遗憾。 不久以后听说Milo Yip（叶劲峰）已开始着手翻译，甚为欣喜。翻译此巨著，他一定是比我更合适的人选。我和Milo虽未曾蒙面，但神交已久。在网络上读过一些他的成长经历，和我颇为相似，心有戚戚。他对游戏3D实时渲染技术研究精深为我所不及，我们曾通过Google Talk讨论过许多技术问题，他都有独到的见解。翻译工作开始后，Milo是香港人，英文技术术语在香港的中文译法和大陆的有许多不同。但此书由大陆出版社出版，考虑到面对的读者主要是大陆程序员，Milo希望能更符合大陆程序员的用词习惯，所以在翻译一开始就通过Google Docs创建了协作页面，邀请大家共同探讨书中技术名词的中译名。从中我们可以一窥他作为译者的慎重。 三年之后，有幸在出版之前就拿到了完整的译本。这是一本用LaTeX精心排版的800页的电子书，我只花了一周时间，几乎是一口气读完。流畅的阅读享受，绝对不仅仅是因为原著精彩的内容，精美的版面和翔实的译注也加了不少分。 在阅读本书的过程中，我不只一次地获得共鸣。例如在第5章的内存管理系统的介绍中，作者介绍的几种游戏特有的内存管理方法我都曾在项目中用过，而这是第一次有书籍专门将这些方法详尽记录；又如第11章动画系统的介绍，我们也同样在3D引擎开发过程中改进原有动画片段混合方法的经历。虽然书中介绍的每个技术点，都可能可以在某篇论文，某本其他的书的章节，某篇网络blog上见过，但之前却无一本书可以把这些东西放在一起相互参照。对于从事游戏引擎开发的程序员来说，了解各种引擎在处理每个具体问题时的方案是相当重要的。而每种方案又各有利弊，即使不做引擎开发工作而是在某一特定游戏引擎上做游戏开发，从中也可以理解引擎的局限性以及可能的改进方法。尤其是第14章介绍的对游戏性相关系统的设计，各个开发人员几乎都是凭经验设计，很少见有书籍对这些做总结。对于基于渲染引擎做开发的游戏程序员，这是必须面对的工作，这一章会有很大的借鉴意义。 本书作者是业内资深的游戏引擎开发人，他所参于的《神秘海域》和《最后生还者》都是我的个人最爱。在玩游戏的过程中，作为游戏程序员的天性，自然会不断地猜想各个技术点是如何实现的，背后需要怎样的工具支持。能在书中一一得到印证是件特别开心的事情。作者反复强调代码实践的重要性，在书中遍布着C++代码。我不认为这些代码有直接取来使用的价值，但它们极大地帮助了读者理解书中的技术点。书中列出的顽皮狗工作室用lisp方言作为游戏配置脚本的范例也给我很大的启发，有了这些具体的代码示例以及作者本身的一线工程师背景，也让我确信书中那些关于主机游戏开发相关等，我所没有接触过的内容都也绝非泛泛而谈。 国内的游戏开发社区的壮大，主要是随最近十年的MMO风潮而生。而就在大型网络游戏在中国有些畸形发展，让这类游戏偏离电子游戏游戏性的趋势时，我们有幸迎来了为移动设备开发游戏的大潮。游戏开发的重心重新回到游戏性本身。我们更需要去借鉴单机游戏是如何为玩家带来更纯粹的游戏体验，我相信书中记录的各种技术点会变的更有帮助。 资深游戏开发及创业者 云风 @简悦云风 推荐序2 在我认识的许多游戏业开发同仁中，只有少数香港同胞，Milo Yip（叶劲峰）却正是这样一位给我印象非常深刻的优秀香港游戏开发者。我俩认识，是在Milo加入腾讯互动娱乐研发部引擎技术中心后，说来到现在也只是两年多时间。其间，他为人的谦逊务实，对待技术问题的严谨求真态度，对算法设计和性能优化的娴熟技术，都为人所称道。Milo一丝不苟的工作风格，甚至表现在对待技术文档排版这类事情上（Milo常执著地用LaTeX将技术文档排到完美），我想这一定是他在香港读大学、硕士及在香港理工大学的多媒体创新中心从事研究员，一贯沿袭至今的好作风。 我很高兴腾讯游戏有实力吸引到这样优秀的技术专家；即使在其已从上海迁回香港家中，依然选择到深圳腾讯互动娱乐总部工作。叶兄从此工作日每天早晚过关，来往香港和深圳两地，虽有舟车劳顿，但是兼顾了对家庭的照顾和在游戏引擎方面的专业研究，希望这样的状况是令他满意的。 认识叶兄当时，我便知道他在进行Jason Gregory所著《游戏引擎架构》一书的中译工作。因为自己从前也有业余翻译游戏开发有关书籍的经历，所以我能理解其中的辛苦和责任重大，对叶兄也更多一分钦佩。我以为，本书以及本书的中文读者最大的幸运便是，遇到叶兄这位对游戏有着如同对家对国般强烈责任感，犹如“游戏科学工作者”般的专业译者！ 现在（2013年年末）无疑是游戏史上对独立游戏制作者最友好的年代。开发设备方便获得（相对过往仅由主机厂商授权才能获得专利开发设备，现在有一台智能手机和一台个人电脑就可以开发）、技术工具友好、调试过程简单方便，且互联网上有丰富的例程和开源代码参考，也有网上社区便于交流。很多爱好者能够很快地制作出可运行的游戏原型，其中一些也能发布到应用商店。 但是不全面掌握各方面知识，尤其是游戏引擎架构知识，往往只能停留在勉强修改、凑合重用别人提供的资源的应用程度上，难以做极限的性能改进，更妄谈革命式的架构创新。这样的程度是很难在成千上万的游戏中脱颖而出的。我们所认可的真正的游戏大作，必定是在某方面大幅超越用户期待的产品。为了打造这样的产品，游戏内容创作者（策划、美术等）需要“戴着镣铐跳舞”（在当前的机能下争取更多的创作自由度），而引擎架构合理的游戏可以经得起──也值得进行──反复优化，最终可以提供更多的自由度，这是大作出现的技术前提。 书的作者、译者、出版社的编者，加上读者，大家是因书而结缘的有缘人。因叶兄这本《游戏引擎架构》译著而在线上线下相识的读者们，你们是不是因“了解游戏引擎架构，从而制作/优化好游戏”这样的理想而结了缘呢？ 亲爱的读者，愿你的游戏有一天因谜题巧妙绝伦、趣味超凡、虚拟世界气势磅礴、视觉效果逼真精美等专业因素取得业界褒奖，并得到玩家真诚的赞美。希望届时曾读叶兄这本《游戏引擎架构》译作的你，也可以回馈社会，回馈游戏开发的学习社区，帮助新人。希望你也可以建立微信公众号、博客等，或翻译游戏开发书籍，造福外语不好的读者，所以如果你的外语（英语、日语、韩语之于游戏行业比较重要）水平仍需精进，现在也可以同步加油了！ 腾讯《天天爱消除》游戏团队Leader 沙鹰 @也是沙鹰 译序 数千年以来，艺术家们通过文学、绘画、雕塑、建筑、音乐、舞蹈、戏剧等传统艺术形式充实人类的精神层面。自20世纪中叶，计算机的普及派生出另一种艺术形式──电子游戏。游戏结合了上述传统艺术以及近代科技派生的其他艺术（如摄影、电影、动画），并且完全脱离了艺术欣赏这种单向传递的方式──游戏必然是互动的，“玩家”并不是“读者”、“观众”或“听众”，而是进入游戏世界、感知并对世界做出反应的参与者。 基于游戏的互动本质，游戏的制作通常比其他大众艺术复杂。商业游戏的制作通常需要各种人才的参与，而他们则需要依赖各种工具及科技。游戏引擎便是专门为游戏而设计的工具及科技集成。之所以称为引擎，如同交通工具中的引擎，提供了最核心的技术部分。因为复杂，研发成本高，人们不希望制作每款游戏（或车款）时都重新设计引擎，重用性是游戏引擎的一个重要设计目标。 然而，各游戏本身的性质以及平台的差异，使研发完全通用的游戏引擎变得极困难，甚至不可能。市面上出售的游戏引擎，有一些虽然已经达到很高的技术水平，但在商业应用中，很多时候还是需要因应个别游戏项目对引擎改造、整合、扩展及优化。因此，即使能使用市面上最好的商用引擎或自研引擎，我们仍需要理解当中的架构、各种机制和技术，并且分析及解决在制作中遇到的问题。这些也是译者曾任于上海两家工作室时的主要工作范畴。 选择翻译此著作，主要原因是在阅读中得到共鸣，并且能知悉一些知名游戏作品实际上所采用的方案。有感坊间大部分游戏开发书籍并不是由业内人士执笔，内容只足够应付一些最简单的游戏开发，欠缺宏观比较各种方案，技术与当今实际情况也有很大差距。而一些Gems类丛书虽然偶有好文章，但受形式所限欠缺系统性、全面性。难得本书原作者身为世界一流游戏工作室的资深游戏开发者（注1），在繁重的游戏开发工作外，还在大学教授游戏开发课程以至编写本著作。此外，从与内地同事的交流中，了解到许多从业者不愿意阅读外文书籍。为了普及知识及反馈业界社会，希望能尽绵力。 或许有些人以为本著作是针对单机／游戏机游戏的，并不适合国内以网游为主的环境。但译者认为这是一种误解，许多游戏本身所涉及的技术是具通用性的。例如游戏性相关的游戏性系统、场景管理、人工智能、物理模拟等部分，许多时候也会同时用于网游的前台和后台。现时，一些动作为主、非MMO的国内端游甚至会直接在后台运行传统意义上的游戏引擎。至于前台相关的技术，单机和端游的区别更少。此外，随着近年移动终端的兴起，其硬件性能已超越传统掌上游戏机，开发手游所需的技术与传统掌上游戏机并无太大差异。还可预料，现时单机／游戏机的一些较高级的架构及技术，将在不远的未来着陆移动终端平台。 译者认为，本书涵括游戏开发技术的方方面面，同时适合入门及经验丰富的游戏程序员。书名中的架构二字，并不单是给出一个系统结构图，而是描述每个子系统的需求、相关技术及与其他子系统的关系。对译者本人而言，本书的第11章（动画系统）及第14章（运行时游戏性基础系统）是本书特別精彩之处，含有许多少见于其他书籍的内容。而第10章（渲染引擎）由于是游戏引擎中的一个极大的部分，有限的篇幅可能未能覆盖广度及深度，推荐读者参考[1]（注2），人工智能方面也需参考其他专著。 本译作采用LaTeX排版（注3），以Inkscape编译矢量图片。为了令阅读更流畅，内文中的网址都统一改以脚注标示。另外，由于现时游戏开发相关的文献以英文为主，而且游戏开发涉及的知识面很广，本译作尽量以括号形式保留英文术语。为了方便读者查找内容，在附录中增设中英文双向索引（索引条目与原著的不同）。 本人在香港成长学习及工作，至2008年才赴内地游戏工作室工作，不黯内地的中文写作及用字习惯，翻译中曾遇到不少困难。有幸得到出版社人员以及良师益友的帮助，才能完成本译作。特别感谢周筠老师支持本作的提案，并耐心地给予协助及鼓励。编辑张春雨老师和卢鸫翔老师，以及好友余晟给予了大量翻译上的知识及指导。也感谢游戏业界专家云风、大宝和Dave给予了许多宝贵意见。此书的翻译及排版工作比预期更花时间，感谢妻子及儿女们的体谅。此次翻译工作历时三年半，因工作及家庭事宜导致严重延误，唯有在翻译及排版工作上更尽心尽力，希望求得等待此译作的读者们谅解。无论是批评或建议，诚希阁下通过电邮miloyip@gmail.com、新浪微博、豆瓣等渠道不吝赐教。 叶劲峰（Milo Yip） 2013年10月 原作者是顽皮狗（Naughty Dog）《神秘海域（Uncharted）》系列的通才程序员、《最后生还者（The Last of Us）》的首席程序员，之前还曾在EA和Midway工作。 中括号表示引用附录中的参考文献。一些参考条目加入了其中译本的信息。 具体是使用CTEX套装，它是在MiKTeX的基础上增加中文的支持。 前言 最早的电子游戏完全由硬件构成，但微处理器（microprocessor）的高速发展完全改变了游戏的面貌。现在的游戏是在多用途的PC和专门的电子游戏主机（video game console）上玩的，凭借软件带来绝妙的游戏体验。从最初的游戏诞生至今已有半个世纪，但很多人仍然认为游戏是一个未成熟的产业。即使游戏可能是个年轻的产业，若仔细观察，也会发现它正在高速发展。 现时游戏已成为一个上百亿美元的产业，覆盖不同年龄、性别的广泛受众。 千变万化的游戏，可以分为从纸牌游戏到大型多人在线游戏（massively multiplayer online game，MMOG）等多个种类（category）和“类型（genre）”（注1），也可以运行在任何装有微芯片（microchip）的设备上 。你现在可以在PC、手机及多种特别为游戏而设计的手持/电视游戏主机上玩游戏。家用电视游戏通常代表最尖端的游戏科技，又由于它们是周期性地推出新版本，因此有游戏机“世代”（generation）的说法。最新一代（注2）的游戏机包括微软的Xbox 360和索尼的PlayStation 3，但一定不可忽视长盛不衰的PC，以及最近非常流行的任天堂Wii。 最近，剧增的下载式休闲游戏，使这个多样化的商业游戏世界变得更复杂。虽然如此，大型游戏仍然是一门大生意。今天的游戏平台非常复杂，有难以置信的运算能力，这使软件的复杂度得以进一步提升。所有这些先进的软件都需要由人创造出来，这导致团队人数增加，开发成本上涨。随着产业变得成熟，开发团队要寻求更好、更高效的方式去制作产品，可复用软件（reusable software）和中间件（middleware）便应运而生，以补偿软件复杂度的提升。 由于有这么多风格迥异的游戏及多种游戏平台，因此不可能存在单一理想的软件方案。然而，业界已经发展出一些模式 ，也有大量的潜在方案可供选择。现今的问题是如何找到一个合适的方案去迎合某个项目的需要。再进一步，开发团队必须考虑项目的方方面面，以及如何把各方面集成。对于一个崭新的游戏设计，鲜有可能找到一个完美搭配游戏设计各方面的软件包。 现时业界内的老手，入行时都是“开荒牛”。我们这代人很少是计算机科学专业出身（Matt的专业是航空工程、Jason的专业是系统设计工程），但现时很多学院已设有游戏开发的课程和学位。时至今日，为了获取有用的游戏开发信息，学生和开发者必须找到好的途径。对于高端的图形技术，从研究到实践都有大量高质量的信息。可是，这些信息经常不能直接应用到游戏的生产环境，或者没有一个生产级质量的实现。对于图形以外的游戏开发技术，市面上有一些所谓的入门书籍，没提及参考文献就描述很多内容细节，像自己发明的一样。这种做法根本没有用处，甚至经常带有不准确的内容。另一方面，市场上有一些高端的专门领域书籍，例如物理、碰撞、人工智能等。可是，这类书或者啰嗦到让你难以忍受，或者高深到让部分读者无法理解，又或者内容过于零散而难于融会贯通。有一些甚至会直接和某项技术挂钩，软硬件一旦改动，其内容就会迅速过时。 此外，互联网也是收集相关知识的绝佳工具。可是，除非你确实知道要找些什么，否则断链、不准确的资料、质量差的内容也会成为学习障碍。 好在，我们有Jason Gregory，他是一位拥有在顽皮狗（Naughty Dog）工作经验的业界老手，而顽皮狗是全球高度瞩目的游戏工作室之一。Jason在南加州大学教授游戏编程课程时，找不到概括游戏架构的教科书。值得庆幸的是，他承担了这个任务，填补了这个空白。 Jason把应用到实际发行游戏的生产级别知识，以及整个游戏开发的大局编集于本书。他凭经验，不仅融汇了游戏开发的概念和技巧，还用实际的代码示例及实现例子去说明怎样贯通知识来制作游戏。本书的引用及参考文献可以让读者更深入探索游戏开发过程的各方面。虽然例子经常是基于某些技术的，但是概念和技巧是用来实际创作游戏的，它们可以超越个别引擎或API的束缚。 本书是一本我们入行做游戏时想要的书。我们认为本书能让入门者增长知识，也能为有经验者开拓更大的视野。 Jeff Lander（注3） Matthew Whiting（注4） 译注：Genre一词在文学中为体裁。电影和游戏里通常译作类型。不同的游戏类型可见1.2节。 译注：按一般说法，2005年至今属于第7个游戏机世代。这3款游戏机的发行年份为Xbox 360（2005）、PlayStation 3（2006）、Wii（2006）。有关游戏机世代可参考维基百科。 译注：Jeff Lander现时为Darwin 3D公司的首席技术总监、Game Tech公司创始人，曾为艺电首席程序员、Luxoflux公司游戏性及动画技术程序员。 译注：Matthew Whiting现时为Wholesale Algorithms公司程序员，曾为Luxoflux公司首席软件工程师、Insomniac Games公司程序员。 序言 欢迎来到《游戏引擎架构》世界。本书旨在全面探讨典型商业游戏引擎的主要组件。游戏编程是一个庞大的主题，有许多内容需要讨论。不过相信你会发现，我们讨论的深度将足以使你充分理解本书所涵盖的工程理论及常用实践的方方面面。话虽如此，令人着迷的漫长游戏编程之旅其实才刚刚启程。与此相关的每项技术都包含丰富内容，本书将为你打下基础，并引领你进入更广阔的学习空间。 本书焦点在于游戏引擎的技术及架构。我们会探讨商业游戏引擎中，各个子系统的相关理论，以及实现这些理论所需要的典型数据结构、算法和软件接口。游戏引擎与游戏的界限颇为模糊。我们将把注意力集中在引擎本身，包括多个低阶基础系统（low-level foundation system）、渲染引擎（rendering engine）、碰撞系统（collision system）、物理模拟（physics simulation）、人物动画（character animation），及一个我称为游戏性基础层（gameplay foundation layer）的深入讨论。此层包括游戏对象模型（game object model）、世界编辑器（world editor）、事件系统（event system）及脚本系统（scripting system）。我们也将会接触游戏性编程（gameplay programming）的多个方面，包括玩家机制（player mechanics）、摄像机（camera）及人工智能（artificial intelligence，AI）。然而，这类讨论会被限制在游戏性系统和引擎接口范围。 本书可以作为大学中等级游戏程序设计中两到三门课程的教材。当然，本书也适合软件工程师、业余爱好者、自学的游戏程序员，以及游戏行业从业人员。通过阅读本书，资历较浅的游戏程序员可以巩固他们所学的游戏数学、引擎架构及游戏科技方面的知识。专注某一领域的资深程序员也能从本书更为全面的介绍中获益。 为了更好地学习本书内容，你需要掌握基本的面向对象编程概念并至少拥有一些C++编程经验。尽管游戏行业已经开始尝试使用一些新的、令人兴奋的编程语言，然而工业级的3D游戏引擎仍然是用C或C++编写的，任何认真的游戏程序员都应该掌握C++。我们将在第3章重温一些面向对象编程的基本原则，毫无疑问，你还会从本书学到一些C++的小技巧，不过C++的基础最好还是通过阅读[39]、[31]及[32]来获得。如果你对C++已经有点生疏，建议你在阅读本书的同时，最好能重温这几本或者类似书籍。如果你完全没有C++经验，在看本书之前，可以考虑先阅读[39]的前几章，或者尝试学习一些C++的在线教程。 学习编程技能最好的方法就是写代码。在阅读本书时，强烈建议你选择一些特别感兴趣的主题付诸实践。举例来说，如果你觉得人物动画很有趣，那么可以首先安装OGRE，并测试一下它的蒙皮动画示范。接着还可以尝试用OGRE实现本书谈及的一些动画混合技巧。下一步你可能会打算用游戏手柄控制人物在平面上行走。等你能玩转一些简单的东西了，就应该以此为基础，继续前进！之后可以转移到另一个游戏技术范畴，周而复始。这些项目是什么并不重要，重要的是你在实践游戏编程的艺术，而不是纸上谈兵。 游戏科技是一个活生生、会呼吸的家伙 ，永远不可能将之束缚于书本之上 。因此，附加的资源、勘误、更新、示例代码、项目构思等已经发到本书的网站。 目录 推荐序1 iii推荐序2 v译序 vii序言 xvii前言 xix致谢 xxi第一部分 基础 1第1章 导论 31.1 典型游戏团队的结构 41.2 游戏是什么 71.3 游戏引擎是什么 101.4 不同游戏类型中的引擎差异 111.5 游戏引擎概观 221.6 运行时引擎架构 271.7 工具及资产管道 46第2章 专业工具 532.1 版本控制 532.2 微软Visual Studio 612.3 剖析工具 782.4 内存泄漏和损坏检测 792.5 其他工具 80第3章 游戏软件工程基础 833.1 重温C++及最佳实践 833.2 C/C++的数据、代码及内存 903.3 捕捉及处理错误 118第4章 游戏所需的三维数学 1254.1 在二维中解决三维问题 1254.2 点和矢量 1254.3 矩阵 1394.4 四元数 1564.5 比较各种旋转表达方式 1644.6 其他数学对象 1684.7 硬件加速的SIMD运算 1734.8 产生随机数 180第二部分 低阶引擎系统 183第5章 游戏支持系统 1855.1 子系统的启动和终止 1855.2 内存管理 1935.3 容器 2085.4 字符串 2255.5 引擎配置 234第6章 资源及文件系统 2416.1 文件系统 2416.2 资源管理器 251第7章 游戏循环及实时模拟 2777.1 渲染循环 2777.2 游戏循环 2787.3 游戏循环的架构风格 2807.4 抽象时间线 2837.5 测量及处理时间 2857.6 多处理器的游戏循环 2967.7 网络多人游戏循环 304第8章 人体学接口设备（HID） 3098.1 各种人体学接口设备 3098.2 人体学接口设备的接口技术 3118.3 输入类型 3128.4 输出类型 3168.5 游戏引擎的人体学接口设备系统 3188.6 人体学接口设备使用实践 332第9章 调试及开发工具 3339.1 日志及跟踪 3339.2 调试用的绘图功能 3379.3 游戏内置菜单 3449.4 游戏内置主控台 3479.5 调试用摄像机和游戏暂停 3489.6 作弊 3489.7 屏幕截图及录像 3499.8 游戏内置性能剖析 3499.9 游戏内置的内存统计和泄漏检测 356第三部分 图形及动画 359第10章 渲染引擎 36110.1 采用深度缓冲的三角形光栅化基础 36110.2 渲染管道 40410.3 高级光照及全局光照 42610.4 视觉效果和覆盖层 43810.5 延伸阅读 446第11章 动画系统 44711.1 角色动画的类型 44711.2 骨骼 45211.3 姿势 45411.4 动画片段 45911.5 蒙皮及生成矩阵调色板 47111.6 动画混合 47611.7 后期处理 49311.8 压缩技术 49611.9 动画系统架构 50111.10 动画管道 50211.11 动作状态机 51511.12 动画控制器 535第12章 碰撞及刚体动力学 53712.1 你想在游戏中加入物理吗 53712.2 碰撞/物理中间件 54212.3 碰撞检测系统 54412.4 刚体动力学 56912.5 整合物理引擎至游戏 60112.6 展望：高级物理功能 616第四部分 游戏性 617第13章 游戏性系统简介 61913.1 剖析游戏世界 61913.2 实现动态元素：游戏对象 62313.3 数据驱动游戏引擎 62613.4 游戏世界编辑器 627第14章 运行时游戏性基础系统 63714.1 游戏性基础系统的组件 63714.2 各种运行时对象模型架构 64014.3 世界组块的数据格式 65714.4 游戏世界的加载和串流 66314.5 对象引用与世界查询 67014.6 实时更新游戏对象 67614.7 事件与消息泵 69014.8 脚本 70714.9 高层次的游戏流程 726第五部分 总结 727第15章 还有更多内容吗 72915.1 一些未谈及的引擎系统 72915.2 游戏性系统 730参考文献 733中文索引 737英文索引 755 参考文献 Tomas Akenine-Moller, Eric Haines, and Naty Hoffman. Real-Time Rendering (3rd Edition). Wellesley, MA: A K Peters, 2008. 中译本：《实时计算机图形学（第2版）》，普建涛译，北京大学出版社，2004. Andrei Alexandrescu. Modern C++ Design: Generic Programming and Design Patterns Applied. Resding, MA: Addison-Wesley, 2001. 中译本：《C++设计新思维：泛型编程与设计模式之应用》，侯捷/於春景译，华中科技大学出版社，2003. Grenville Armitage, Mark Claypool and Philip Branch. Networking and Online Games: Understanding and Engineering Multiplayer Internet Games. New York, NY: John Wiley and Sons, 2006. James Arvo (editor). Graphics Gems II. San Diego, CA: Academic Press, 1991. Grady Booch, Robert A. Maksimchuk, Michael W. Engel, Bobbi J. Young, Jim Conallen, and Kelli A. Houston. Object-Oriented Analysis and Design with Applications (3rd Edition). Reading, MA: Addison-Wesley, 2007. 中译本：《面向对象分析与设计（第3版）》，王海鹏/潘加宇译，电子工业出版社，2012. Mark DeLoura (editor). Game Programming Gems. Hingham, MA: Charles River Media, 2000. 中译本：《游戏编程精粹 1》， 王淑礼译，人民邮电出版社，2004. Mark DeLoura (editor). Game Programming Gems 2. Hingham, MA: Charles River Media, 2001. 中译本：《游戏编程精粹 2》，袁国忠译，人民邮电出版社，2003. Philip Dutré, Kavita Bala and Philippe Bekaert. Advanced Global Illumination (2nd Edition). Wellesley, MA: A K Peters, 2006. David H. Eberly. 3D Game Engine Design: A Practical Approach to Real-Time Computer Graphics. San Francisco, CA: Morgan Kaufmann, 2001. 国内英文版：《3D游戏引擎设计：实时计算机图形学的应用方法（第2版）》，人民邮电出版社，2009. David H. Eberly. 3D Game Engine Architecture: Engineering Real-Time Applications with Wild Magic. San Francisco, CA: Morgan Kaufmann, 2005. David H. Eberly. Game Physics. San Francisco, CA: Morgan Kaufmann, 2003. Christer Ericson. Real-Time Collision Detection. San Francisco, CA: Morgan Kaufmann, 2005. 中译本：《实时碰撞检测算法技术》，刘天慧译，清华大学出版社，2010. Randima Fernando (editor). GPU Gems: Programming Techniques, Tips and Tricks for Real-Time Graphics. Reading, MA: Addison-Wesley, 2004. 中译本：《GPU精粹：实时图形编程的技术、技巧和技艺》，姚勇译，人民邮电出版社，2006. James D. Foley, Andries van Dam, Steven K. Feiner, and John F. Hughes. Computer Graphics: Principles and Practice in C (2nd Edition). Reading, MA: Addison-Wesley, 1995. 中译本：《计算机图形学原理及实践──C语言描述》，唐泽圣/董士海/李华/吴恩华/汪国平译，机械工业出版社，2004. Grant R. Fowles and George L. Cassiday. Analytical Mechanics (7th Edition). Pacific Grove, CA: Brooks Cole, 2005. John David Funge. AI for Games and Animation: A Cognitive Modeling Approach. Wellesley, MA: A K Peters, 1999. Erich Gamma, Richard Helm, Ralph Johnson, and John M. Vlissiddes. Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addison-Wesley, 1994. 中译本：《设计模式：可复用面向对象软件的基础》，李英军/马晓星/蔡敏/刘建中译，机械工业出版社，2005. Andrew S. Glassner (editor). Graphics Gems I. San Francisco, CA: Morgan Kaufmann, 1990. Paul S. Heckbert (editor). Graphics Gems IV. San Diego, CA: Academic Press, 1994. Maurice Herlihy, Nir Shavit. The Art of Multiprocessor Programming. San Francisco, CA: Morgan Kaufmann, 2008. 中译本：《多处理器编程的艺术》，金海/胡侃译，机械工业出版社，2009. Roberto Ierusalimschy, Luiz Henrique de Figueiredo and Waldemar Celes. Lua 5.1 Reference Manual. Lua.org, 2006. Roberto Ierusalimschy. Programming in Lua, 2nd Edition. Lua.org, 2006. 中译本：《Lua程序设计（第2版）》，周惟迪译，电子工业出版社，2008. Isaac Victor Kerlow. The Art of 3-D Computer Animation and Imaging (2nd Edition). New York, NY: John Wiley and Sons, 2000. David Kirk (editor). Graphics Gems III. San Francisco, CA: Morgan Kaufmann, 1994. Danny Kodicek. Mathematics and Physics for Game Programmers. Hingham, MA: Charles River Media, 2005. Raph Koster. A Theory of Fun for Game Design. Phoenix, AZ: Paraglyph, 2004. 中译本：《快乐之道：游戏设计的黄金法则》，姜文斌等译，百家出版社，2005. John Lakos. Large-Scale C++ Software Design. Reading, MA: Addison-Wesley, 1995. 中译本：《大规模C++程序设计》，李师贤/明仲/曾新红/刘显明译，中国电力出版社，2003. Eric Lengyel. Mathematics for 3D Game Programming and Computer Graphics (2nd Edition). Hingham, MA: Charles River Media, 2003. Tuoc V. Luong, James S. H. Lok, David J. Taylor and Kevin Driscoll. Internationalization: Developing Software for Global Markets. New York, NY: John Wiley & Sons, 1995. Steve Maguire. Writing Solid Code: Microsoft's Techniques for Developing Bug Free C Programs. Bellevue, WA: Microsoft Press, 1993. 国内英文版：《编程精粹：编写高质量C语言代码》，人民邮电出版社，2009. Scott Meyers. Effective C++: 55 Specific Ways to Improve Your Programs and Designs (3rd Edition). Reading, MA: Addison-Wesley, 2005. 中译本：《Effective C++：改善程序与设计的55个具体做法（第3版）》，侯捷译，电子工业出版社，2011. Scott Meyers. More Effective C++: 35 New Ways to Improve Your Programs and Designs. Reading, MA: Addison-Wesley, 1996. 中译本：《More Effective C++：35个改善编程与设计的有效方法（中文版）》，侯捷译，电子工业出版社，2011. Scott Meyers. Effective STL: 50 Specific Ways to Improve Your Use of the Standard Template Library. Reading, MA: Addison-Wesley, 2001. 中译本：《Effective STL：50条有效使用STL的经验》，潘爱民/陈铭/邹开红译，电子工业出版社，2013. Ian Millington. Game Physics Engine Development. San Francisco, CA: Morgan Kaufmann, 2007. Hubert Nguyen (editor). GPU Gems 3. Reading, MA: Addison-Wesley, 2007. 中译本：《GPU精粹3》，杨柏林/陈根浪/王聪译，清华大学出版社，2010. Alan W. Paeth (editor). Graphics Gems V. San Francisco, CA: Morgan Kaufmann, 1995. C. Michael Pilato, Ben Collins-Sussman, and Brian W. Fitzpatrick. Version Control with Subversion (2nd Edition). Sebastopol , CA: O'Reilly Media, 2008. （常被称作“The Subversion Book”，线上版本.） 国内英文版：《使用Subversion进行版本控制》，开明出版社，2009. Matt Pharr (editor). GPU Gems 2: Programming Techniques for High-Performance Graphics and General-Purpose Computation. Reading, MA: Addison-Wesley, 2005. 中译本：《GPU精粹2：高性能图形芯片和通用计算编程技巧》，龚敏敏译，清华大学出版社，2007. Bjarne Stroustrup. The C++ Programming Language, Special Edition (3rd Edition). Reading, MA: Addison-Wesley, 2000. 中译本《C++程序设计语言（特别版）》，裘宗燕译，机械工业出版社，2010. Dante Treglia (editor). Game Programming Gems 3. Hingham, MA: Charles River Media, 2002. 中译本：《游戏编程精粹3》，张磊译，人民邮电出版社，2003. Gino van den Bergen. Collision Detection in Interactive 3D Environments. San Francisco, CA: Morgan Kaufmann, 2003. Alan Watt. 3D Computer Graphics (3rd Edition). Reading, MA: Addison Wesley, 1999. James Whitehead II, Bryan McLemore and Matthew Orlando. World of Warcraft Programming: A Guide and Reference for Creating WoW Addons. New York, NY: John Wiley & Sons, 2008. 中译本：《魔兽世界编程宝典：World of Warcraft Addons完全参考手册》，杨柏林/张卫星/王聪译，清华大学出版社，2010. Richard Williams. The Animator's Survival Kit. London, England: Faber & Faber, 2002. 中译本：《原动画基础教程：动画人的生存手册》，邓晓娥译，中国青年出版社，2006. 勘误 第1次印册（2014年2月） P.xviii: 译注中 Wholesale Algoithms -> Wholesale Algorithms P.10: 最后一段第一行 微软的媒体播放器 -> 微软的Windows Media Player (多谢读者OpenGPU来函指正) P.15: 1.4.3节第三点 按妞 -> 按钮 (多谢读者一个小小凡人来函指正) P.40: 正文最后一行 按扭 -> 按钮 P.50: 1.7.8节第二节第一行 同是 -> 同时 (多谢读者czfdd来函指正) P.98: 代码 writeExampleStruct(Example& ex, Stream& ex) 中 Stream& ex -> Stream& stream (多谢读者Snow来函指正) P.106: 第一段中有六处 BBS -> BSS，最后一段代码的注释也有同样错误 (多谢读者trout来函指正) P.119: 译注中 软体工程 -> 软件工程 (多谢读者Snow来函指正) P.214: 正文第一段有两处 虚内存 -> 虚拟内存 (多谢读者Snow来函指正) P.216: 脚注24应标明为译注 (多谢读者Snow来函指正) P.221: 第一段代码的第二个断言应为 ASSERT(link.m_pPrev != NULL); (多谢读者Snow来函指正) P.230: 5.4.4.1节 第二段 软体 -> 软件 P.286: 脚注4应标明为译注 (多谢读者Snow来函指正) P.322: 第二段 按扭事件字 -> 按钮事件 P.349: 9.8节第二段第二行两处 部析器 -> 剖析器 (多谢读者Snow来函指正) P.738-572: 双数页页眉 参考文献 -> 中文索引 P.755-772: 双数页页眉 参考文献 -> 英文索引 P.755: kd tree项应归入K而不是Symbols 以上的错误已于第2次印册中修正。 第2次印册及之前 P.11: 第四行 细致程度 -> 层次细节 (这是level-of-detail/LOD的内地通译，多谢读者OpenGPU来函指正) P.12: 正文第一段及图1.2标题 使命之唤 -> 使命召唤 (多谢读者OpenGPU来函指正) P.12: 正文第一段 战栗时空 -> 半条命 (多谢读者OpenGPU来函指正) P.16: 第一点 表面下散射 -> 次表面散射 (多谢读者OpenGPU来函指正) P.17: 1.4.4节第五行 次文化 -> 亚文化 (此译法在内地更常用。多谢读者OpenGPU来函提示) P.22: 战栗时空 -> 半条命 P.24: 战栗时空2 -> 半条命2 P.34: 1.6.8.2节第一行 提呈 -> 提交 (这术语在本书其他地方都写作提交。多谢读者OpenGPU来函提示) P.35: 第七行 提呈 -> 提交 (这术语在本书其他地方都写作提交。多谢读者OpenGPU来函提示) P.50: 战栗时空2 -> 半条命2 P.365: 第四段第二行: 细致程度 -> 层次细节 P.441: 10.4.3.2节第三行 细致程度 -> 层次细节 P.494: sinusiod -> sinusoid (多谢读者OpenGPU来函指正) P.511: 11.10.4节第一行 谈入 -> 淡入 (多谢读者Snow来函指正) P.541: 战栗时空2 -> 半条命2 P.627: 战栗时空2 -> 半条命2 P.654: 第二行 建康值 -> 血量 (原来是改正错别字，但译者发现应改作前后统一使用的“血量”。多谢读者Snow来函指正) P.692: 第二行 内部分式 -> 内部方式 (多谢读者Snow来函指正) P.696: 14.7.6节第四行 不设实际 -> 不切实际 (多谢读者Snow来函指正) 以上的错误已于第3次印册中修正。 其他意见 P.220: 正文第一段 m_root.m_pElement 和 P.218 第一段代码中的 m_pElem 不统一。原文有此问题，但因为它们是不同的struct，暂不列作错误。 (多谢读者Snow来函提示) P.331: 8.5.8节第二段中 “反覆”较常见的写法为“反复”，但前者也是正确的，暂不列作错误。 (多谢读者Snow来函提示) P.390: 10.1.3.3节静态光照第二段中“取而代之，我们会使用一张光照纹理贴到所有受光源影响范围内的物体上。这样做能令动态物体经过光源时得到正确的光照。” 后面的一句与前句好像难以一起理解。译者认为，作者应该是指，使用同一静态光源去为静态物件生成光照纹理，以及用于动态对象的光照，能使两者的效果维持一致性。译者会考虑对译文作出改善或加入译注解译。（多谢读者店残来函查询） P.689: 第五行 并行处理世代 -> 并行处理时代 是对era较准确的翻译。 (多谢读者Snow来函提示) 本篇文章为转载内容。原文链接：https://blog.csdn.net/mypongo/article/details/38388381。 该文由互联网用户投稿提供，文中观点代表作者本人意见，并不代表本站的立场。 作为信息平台，本站仅提供文章转载服务，并不拥有其所有权，也不对文章内容的真实性、准确性和合法性承担责任。 如发现本文存在侵权、违法、违规或事实不符的情况，请及时联系我们，我们将第一时间进行核实并删除相应内容。

...们知道了 列出是下标索引为3的数据 软卧是下标索引为23的数据if tem_list[23] != '无' and tem_list[23] != '':print(tem_list[3],'有票',tem_list[23])else:print(tem_list[3],'无票') 三、session Session与cookie功能效果相同。Session与Cookie的区别在于Session是记录在服务端的，而Cookie是记录在客户端的。 由于cookie 是存在用户端，而且它本身存储的尺寸大小也有限，最关键是用户可以是可见的，并可以随意的修改，很不安全。那如何又要安全，又可以方便的全局读取信息呢？于是，这个时候，一种新的存储会话机制：session 诞生了 突破12306验证码import requestsreq = requests.session() 保持会话def login(): 笔记本 win7 python3.6 获取验证码图片pic_response = req.get('https://kyfw.12306.cn/passport/captcha/captcha-image?login_site=E&module=login&rand=sjrand')codeImage = pic_response.contentfn = open('code2.png','wb')fn.write(codeImage)fn.close() 从验证码图片的左上角 (0,0)codeStr = input('请输入验证码坐标:')headers = {'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.128 Safari/537.36'}data = {'answer': codeStr,'rand': 'sjrand','login_site': 'E'}response = req.post('https://kyfw.12306.cn/passport/captcha/captcha-check',data=data,headers=headers)print(response.text)login() base64伪加密 根本不算是一种加密算法 只不过它的数据看上去更像密文而已 64个字符来表示任意的二进制数据的方法 使用 A-Z A-Z 0 - 9 + / 这64个字符进行加密 import base64url = '9j/4AAQSkZJRgABAgAAAQABAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAC+ASUDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+ivPNS1bUJdPlW2XWIJZ550EExgZ4mwMplZDkA5IIJwGA7Vd8P63d2Wi39zqC3k32C3VmR9gYkKSQPmJyeMZxQB21FcPqV14igvb/Vfs2qWlklsh8qKS1fGzeWbDk9iOnpU+r6tqVsohtdYij2W48w3GiT3DuxGdweJ0QcEcAcEHnsADsaK4Xwrq2p3un6fBd6zHIk1oqjydGuIpQxQYbzndkyPUrg0zXZdR0fxLpVqmq65c2k9rdTTpbpC8i+W0IDAbMkASNkAEnjAoA72iuH1C6iNlpk1tr11d2lxcPula7WDpE+FLoF24YDIIyCMYzxXKXOoapB4f1W4k1PUY5LfT7qaOctcxqZlVygjJkZWA25ywGRt4OTgA9jorh/Eev3507xBFb3OnWwtN0S75mWU/u1bcMdPvcfSpdS8RahBZ6lEtxYNLHps1zHNZuWKMm0DIOR/F+lKTsrl04OpNQW7djs6K8t/te+WGCAXOvLM9zsuws0MsxHkGUeWfuKMEE+2e9Ra/4hktvDVguma1qkEt+gWOC9MJdkZjmV5D90EHAO4AYHTBrneJik3Y9eOSVZTjBSXvPz89dL9vu7Hq9FeZaHrl5LqmnaWNcvCsjeWn76yuOFUthim5uQOp596ojxbq41DUzFqFrK90lwDAWZfsQh+VW64GRljgZJFH1mNr2BZHWcnFSW1+vd+Wmz+63VHrMjFY2YKWIGQoxk+3NUrqVUjYsu7A3BfUjkVgeFb3UvPvtLvr2C9Sxt7dormNWzKHDHcxLHJwo596xfiDqSwaTArPKJXmTaYi6nggt8oIz8oPBNbwlzK55mIoOhUdNu+33NXX4Mt/8JpYzR7por+AKoacfZ2YRZB+Vio47Nn3HNXbXXNN1PcLK8hnZQCyo43KPcdRXjuqanNeK+ZZUF2TNIo67XbagOGBPyhVPXp0rUj1S5j0TUrqS4k+1OywJKpJJCcL7/fZqowO91LxFYaeXSWR3lQZZIo2YqM98A449cVVk8Q2K6bHe3Mn2SNwSq3GFY/hz9a83nkEkkcCfbrm1UF2BXyQ0mRgnoT35OT0qCWaUab9ghIjiuLgmUqcg8/d98KOfpQB3sPimwmtYZZC2+WLzMQqZBGM/wARUHHcdualh1SzvmZbWfzSv3sKR3rgI9UuRdvdvetEZAULIqlWCgY657l+nrXWaVc3ctmDdEbyckAbcjPynHrg/rQB6boMirotvyxJD8844c/gOv4/hVRPEVjd6zPp0LO0sEZZnH3Cd2Co9SCOfSqcInl8JxwW832eSQMDKFyVBY5I98dD2rn7qODTby2vEnS1gt42iKtwHDHPJJ65596ANiXxboonngnujbyI+1xco0YDYBGN3HTBGPXNRyeJdGZlRdStXdyAqLICWPbAHWvPLbVXO+8Muo28t07TF4gJUYMePlw2MDA6DpV3Rr4rDeXzM0zvIQrmMKxVRjGAB33du9AHS6h4n0q1n8s3HmygldsKGQ59OOh4z+FZkXjbT3jSacTW/wAwU74CVDDsTjBP/wBevN9SvRLeAhMRISqLIVPJ5JOdwJ65OByabYXKxwlHgt5M/wALsAfqOP60AfUekyxzaNYyxOHje3jZWHRgVGDVysvw1j/hFdHwu0fYYcKDnHyDjNalABRRRQAUUUUAFFFFABRRRQByNx4PuL3UfNu7yJrX7XLcLEIEbYGXA++rBie5wMcY7kw6b4V1GLTtStLiLTok1CdFliXbKnkAYcYEUalmGRgrgZzk4xXXedJ/z7S/mv8A8VR50n/PtL+a/wDxVAHGj4a6KSUfSdEMTNcKSNLgDBH5jIIT7yfdHYjrk1pnT9fjlSdDp80r2EdtOGkeNRIpYllAU8Hd09q3/Ok/59pfzX/4qjzpP+faX81/+KoA5/SNL1q2u9JW9WyFtYWT25aCZ2Z2xGASpUD+A9+9XrvSp5/Fml6qrRiC0tLqB1JO4tI0JUgYxj922ee461pedJ/z7S/mv/xVHnSf8+0v5r/8VQBla3pd5dyWL6cbeJoJpHk8wsuQ0bqSCvO7LA5rmb7wZr8unaxb29/ZFtRsZrRlmUYJdSAxcJv4yepI56V3fnSf8+0v5r/8VR50n/PtL+a//FUAZWueH7XUdJ1GKCztftV1Gw8x4xkuQACTjPQDn2pus+Hob3R762sIbW1urm3aATeUBhWxkHHY4rX86T/n2l/Nf/iqPOk/59pfzX/4qk1dWZdObpzU47rU51/CVvDqNtLYQW1ta28E2Io02l5nUIGOO23d+dV7jwlNc+GNG00tClzaNbCeVSQSkZ+YKcdeTjIrqvOk/wCfaX81/wDiqPOk/wCfaX81/wDiqj2MNTqWYYhcr5tV/wAH/NnJQ+ELyDxVZXqXIawtHZ182YvIxKFcbdoA5J5yah03wjq9nqtvcT3NhNbQm82whGyPOOQCf4h69Mds12fnSf8APtL+a/8AxVHnSf8APtL+a/8AxVT7CH9f15FvNMQ1Z22tt6/j7zOa0TQ7rSjqN1f/AGGA3KwQpBZ58uNI8gDLAZJ3elZfiawXUrZoiSY3HVT1H1rtpnkkiZRbS5Puv+NZlxYTzD/j2J5H3mX/ABrSMVFWRyV60q83Unvp+CseTX+gM7B44oRMpGxnj3bQOg68VB/YlwulxW4lAlSTzd23ILbt3T616lPoFzIDtgAPbLD/ABqtJ4Yum6Qgf8DFUZHmT6XeTE+felVA5EMQQfmc/wA6guNFUwRoNyomSNp9Qe/4mvTv+EUve0Sf99imy+Er98Yjj6c/MBQB5SugF8geaQn3O4jwM5A+gNdNp4nhtBHM43nh1AI5Hf8AU/rXTyeCb9nJSKMDPAMgJpw8IauhwhTABVT5mODnj9T+dAGjpKeZ4ft8HB+fBPTO49RVDVrJJImQxhlPUEcVuabpd7Z6bFbSQ5dM5KsMckn196WTS7yUfNB6/wAYoA8ru9Btt+UtRG2OfKJXP1xiqNppLQac8RZxI6kH5yQMnPAr1G48M3kwOIVz7uBVVvB98RgRx/8AfYoA8duNDbeMlmPYjC/ypBowQYdJAeD949K9bbwNftn91Fn/AK6Co5PAuqSDBSEkYAJk6D0oA7Xwynl+FNHQfw2MI/8AHBWrVDTUms9LtLV7eQtDCkZKlcZCgcc+1WfOk/59pfzX/wCKoAmoqHzpP+faX81/+Ko86T/n2l/Nf/iqAJqKh86T/n2l/Nf/AIqjzpP+faX81/8AiqAJqKh86T/n2l/Nf/iqPOk/59pfzX/4qgCaiofOk/59pfzX/wCKooAmooooAKKKQmgBaKge7hj6yDPoDSR3SSkhT04qeeOw7MsUUgpaoQUUUUAFFFI2QOKAForwP4jeN9UOvTw6fqlzbW0J8kfZp2jyR1PBGc/4VxWi/EPxbpV9DdSazf3MLOV23Nwzo3Q4w2fUduOTx1oA+saK53wd4rtvFujC+hGyRTtljz909iPYjnv3HY10VABRRRQAUUUx84OM5oAfRXByfEjTYpCpulJBwVMTZHtgd6if4l6axwL1UPtC+f5UuZGXt6fWR6DRXnZ+Itht41Nh/wBu7f8AxNIfiNYAD/iaH/wHb/4mlzoPb0+6PRaK83PxIsDwdTP4QN/8TV/QvGNjqutQWkN/LLJIWwhVwD8pPcYppp7Aq0G7Jnc0U1TzWV4jne305GSV48yhSyOVOMHuKmpNQi5djVamvRXGJc3uxNks7DHBNyefzp87X7W8kf2q6gd1IEm8kLx168muT67HsXyM7CiuV+13O8RCeXKqOVkLAgADJPv15560/wC0XRAzPL/32ar65HsTY6eiuXa6uQP9fN1/vmo2vLjn/SJhyf4zR9cj2Cx1lFce95dBM/apv+/hqq1/eY/4/LgH/rof8aPrkewWO6ooorsEFFFFAFO9vVtIixySBnviuan1ma4k2F5RnGwqowc5OQM89scV095bieAr0I5Fca9ssMzbsjewQFjwF69PQA8ew9CMcdeUk7G1NJli3uHkcZLfN2ZSp/I/5xitKKQxyhh171jpKz7XQIuY1Kq0h+XLZ3DOMrtJPTPA6dBy3ivxffWBCWsiWqkcyrh/mPHJ4Xb3BOOo4GCTlHc0kj16GVZVBB59M1LXmHw38S3t2L23vZonERUo4UDPYgkdcfJ15+b349LikEi7h+R7Gu2Er6M52rElFHeitCQpkhIjJHUDOPWmTXVvbDM88cQ9ZHC/zqomt6ZM/lw6javIeAqyqST7c0XA+XtfZXnMkpBBk3EAZGM8gf54zisGK9jhsYrebDItxgeylTn9cflXQePbWXRtXvbSaXLRyFVOMFk7Eg8YI6e2M1wLPLeS7lGfm4XI/wAikI9U8BeLp/Ct8ZZpM2TkKYhycbjux74249xX0jZXkV9axXMDiSGVA6OOjKRwa+KQbuCymW5QhsDYZHwCCeSB346n698V7H8EfHbKX8OX8qKhctaO5wQxOWQ/U8j3yO4oQz3yimI249R0zT6YBTT06ZpTSH7poE2fO2sJdXviDWktoZXP2qQ74oyxU+Y2DxyOh/Oqk1peOy7tIuBkESFYWyfcHPXGce+K6XRGzJrl1yRLcdAMk/ebgDknnoOTXP6lrD3GqT2cI2tkqWMuxowDhs5XOBhskEkAHOOK87nk27HLg8NOVO8dtShcWV5FLhdMvDg4ObdhnpTF0/Uf4tOuwM9oWNTprt9d6msNtO0xVFTfEWfJGRk84xk9eQeOakGo6tc3xNpfbpZlKiDziSoZQwIBPJxgDn+L64Oad7BLKJN3dyfRdLa4nla+sZl2qNiSKybm9vXgdPeu48AWUFl47kjiAVjp0jOgbIB8yPHB5Hf8+9cTomuXdzqxt7rUoTA7Om15g2whgcj164BGc54yAcd94OkJ+J2owAKkUFgVRAOmWjP+R29Kzpxn9YUm9CvqqwyjFx1vueoDrXP+L5zbaZbOHK/6SozjP8LV0AFZXiG/s9P09JL2NZInlEYVgDkkE9/oa68ar4eavbQ7KfxI5C58RLPHHGHEMirtZkfBar9hcyzQ7JJmbCgIwKZz61zc+p2Ty7RYpHH5hXzXJKEdsEf1IqKS3ihVJorpoRngLna3484r4j29aNTWR6XsVa5uaNr8N5rUmnPG8NxzmJ1wCR3B+g5BA/Hmum8nJwBwK8+8L28c/iyzl2O94okM7qNysfmG/PYY2ge5rsH8U2NvBGtwHN0XaNoIBuIIYqT1AxlfrgivocPVvD3ziqxSehf8jPaoZLXJOBWmi74UkZChIyVPUZrO1DUrWwjZpJEGwgFiwCrlgOSSB3zjO44OFY8V1cl9UZWKUltjIIqjJBz/AJNcr4h+Jlpaq0ENuLiUqMbZnjUNkYI+67jkZ+5xnqKk8LzS+OIp7jX7TBXDRQK7LGFJODtAABGDgkkkEj+E0nTajdlRjfVnslFFFeuZBRRRQAjDI5rm9eswZBKCyAnJZTgqfUHBwffFdKaq3luLiB04yw4NY1o3iVB2ZxCRMq/vpFhRmMis0Y2qRzu6lQByRzjnHJGKnlgtL5lhkgimztOHTgZyxwWBVuBjqeMnsaV4WttTi3qDglU+TP3sA49B0JP+yOvSi3nUlJRLG9uSWEezAIYfKM4AACYABzn071wXszpepd07T4rUTacIl8kr5qIOFIzygH+yduDjpgdq2YHkRuGJI65/jH+NULZA80cjtloSRlWyp3Dhc56YIIzgnANWZLiKGVF5dz90Yyfy7fX9a1jKzuZtGtG+9QfWud8deJx4S8NvqQTfIXEUY/2iCf6VtWJmZC8qqpbkAHPHuemfz+przj4+Bz8PoPLzu+3x9P8Ackrui7oweh57B8XLPUp4otX0GS44AkmDrMzHjJCsBjPXGeK04IfCHiASB7K+0uaZig8yN4uD3A5jA+teXaTrlpotgZYY/NvHzncOnPr1xUMvjDV7yXEl28UZP3YTs/XqadkI9Y1/4f3Op6NBFbXv9o20HyWzO+2aOMY+QSfdkAwcA7cZwGAAFcRbeC/K1BLKa9hs5sj9xODE5JOON3Dcg/dJHuap2WvajH5UqXlyWVsrIf3jofZvvL9RzXY2XjK7ghaz1+xGoWWNsiSKCyYIwPm4bAzw/JPO89CAa198Mvtfheazjwb2NN9u7Z4cZwOwAPTnI5rxG2up7G73xjBVsFCe4I9+vT8q9102LT9UDSeDPEU+lXse4vYFsxoc/Putn+7gsFyuAD0ya8w8ceGNestWudR1OxRBO3mSXFsGaBnPVs9VJJAwQOSe1JMD3f4TfEKPxXpzWF3Iw1OzRQ/mMuZl6bhzkkcA8f3T3r0wHIr4r8J+Ibnwr4kstVi3FY2xKg4EkZOGX39u2dp7V9kabeQ39lFdW8gkglQPG46Mp5B/LFUMummN90080x8bD9KBS2Z4docfn+HtQxtzJcMMuAVHydSGIBGD0PB6VzsFuBqV3PbST3G9miWKREVWmI34bBBIznjAxng+u5oE4TQpQSMfalzn0IwSK5TUJtRulaG5ljEJYlVRVLe3OMivJjNKbRGExnsKNr6FsaVd2t/Fv05XBjZ1cxKfNZxk71AIUDDcAHHfrmpLHT7qe+hlSNH+xrs8tmZmKiMKR5fIG4kEDPc+tYralespV5mlVFOCQDjgjOD9a0tO0sXsdtN9tcfaQ5uQh5K5zgDHPXng/XoTtdJXOyOY1KiujWtfDRi1Q3R81FR2mYtdM2Q2QPl2g5yRnJP3D1zmu18GL/xdbWj0xZ4wfrF/n8a5Dw6iR3k8bSzFSocGRjggnr19c5+orsfBJH/CztbA7WoA+mUqaM+aa06nLia860oOfRnqArh/irpUur+F7WCGRY5EvVkBJx0Rx1/Gu471yPxGuPs3h+2kJuABdqD9ni3t9x+3+ecDkkA9OLU3Qlyb2NqTSmmzwe6i8Q6XlQ8+wdGxuB/Hn+dXNKi12+1P7NPdLA8KrI6zyBOCcKDjoSfl69a2/t+qSSRiLTZtpwUEsBByc9R6dD3xvB+bGKvtNNbmGC80iLaTskcCMLsLEbSzAKuMZUHAYnGRwq+XRw14/vkr+h1zrdEdn4S8MWek6W32ae4hvmO6SXfuIODgYOVI+Ynpz17CoNGj0dvELQP9qj1WSR3kZ2UEvktnGOAcE47dBVGDxTHbKbay097med38ydZBa+aqgfOpIyQVU5I4+XOeRUFhosNjqNncrdwRXspLhvPLK5ZAzYbuMeoU85xgrVzpyglZXRzPVnpVzbia2ELyuEYFWZSVYjHZl5U9ORXhfjrSZdD1mK0hkC2MkbmKeUk+QMtuRQx7fzPU173tV05wQwwecg1yHi3wbP4hlg8mWEIgYMZuSdxXtt6YBP1A+o6paJWRMXrqeFWdlcXd5KNIAlaXar3TDepUdcc4Y/N93p0GR0PpHgTwrfNavqD6jeRSOo8u43KRITgtkYIYcA57556V22keAtF00l3gN1I3DG4bcp4Axs+7jgdRkeprqFjUdBxUSjOb12Lc0tieiiivTMAooooAKQjIxS0UAc14ksBMqyYGxv8AWZAIwPUHrxXLrcm3vX+0COFYQA0rNg/KSUI25UDAPHDdW44r0DVFdrGQRJvkONo9Dnr+HX8K5C28DyS3wnvZQcNuzjp7KOgxj8+e9cNSk+fQ6ITXLqRWl1dXxEemB1twFXfIqnpgZUYyenc10lhoYiPmzySFyuG+c5PuT/nitKysLeyjCQoBgYJPJNW8CtoUEviIlUvohkaLGAqKqqAFAHYDoK5f4ieGJfFfhZrG3l2XEcqzRA8BmAIwfwY11dBGa6DI+Kte8PXOlXbW93BNbyKfmDKQCcf5x7fjWPHZkS5VgVHYDJr7a1PQNM1dAt/ZxTgfd3oDj6VhRfDTwxDL5i6cmc98/wAqAPAPAngy/wBZ1eB/JdYI2Du5H5Y9K98k8FWN5YrBdW6yBQQCRyPoa6iz061sIRDbQRxRgcKq4FW8UgPnfxd8Ib+yuV1DRJpC0RV0CZEilemMc8dsciuf034i+JPDcgsdftmv7VcIXfiRQMD72Oen8XPuK+pJYkkXDgEHiuU8Q+BdM12Flnt0MhGA4HPtRYDxk+GvBvjqBrnw9cLYXpG57ULtXA2/ejzwOcbkOASeteg/DTV5tFSPwdrMgTU7dS1sWbK3EWTjYepxz8pCkDHBwTXnviH4OanpMkmoaPM2+D97GIyRICvPy47/AORzXL6Lqurxa9p/iPUnvbyGylRJZ0l/eRKD9193ABB+h3Ebic4QH16ar3rmOzmcc7UY8ewNWGGRWbr8xt/DupTKSrR2srA+hCE05LRiaT0Pn7U9Qs9Ds7a1gzc3EqGTKH5CQxQnJ5xlSB9M98nCn8QXt1lV8qLjosYJ/M5/nV29/sxtO03F15t7JB5bh0+S1Uyu2c4yScg8DueoPC2tjo0LsJdVtSgQgHypXyx+qcD6V5PsYp3sepBYPBUYOcbt9zdtnNnbxJfWrSzqgMkieWozjITlu2QD+faktdSsNRjuJIRtkiZVIMak5bjcTkjqf0P1OLe3ELx3L/2zbyTTKUziUYXuPuc9vyFZj2VobdFg1giUxkSNtkbLE5P8AzzmqjRi9zy5Vabk7M9E0Z4ZY/KMSRhgCMZAY44GcYB4rV8Bvv8AitrRH3fs0g/J48f1rgfCMZ0mWcpP9qhk2/OqMpY+jA9ecflXf/Di6ifxtfRoP3k1q88jf8DTA/I0UqkFVUE7syqK8os9ZFef/F7VINI8Nabc3IkMB1FY3MbAEAxS88j9RgjqCCBXoAryv4/7B4Dsi6qf+JlHjdyAfKl7d/px9a9Rq6sbJnNz67Fc6UJf7XW9ecyTbRbiaUDqqiNxlMBh1yMZIyMGoLuSO1uLe3uZprjYFMjSfIiYwVl2JuKnIYHcgLKoOTg14pGWtpEkhOyVDvDhuQwPBVh3yMjH4muj0/xRqF4IdGvL2LyjPkXd35r7OP7mdpzyfmXOTyR2xdNo0UkdrqmoxQgvb30drCbSOFdswlaIDuoKhlbIPA+YbuB0xn22l6rq2mC/1ETjTynnxX1xGZ5JGKgsOPlOcclwx6gZYFRc8JWnhu7kvri5v/7QvJh5QySrtudlzjbhVIA7cbh6V3EkEjiJBYW8pt2BE8KNbGT5CMbMn5SNvz7jkYHOQKjbcowvCV7fWQXTrXVJbQ6dlmlgt3eBwyNkyAsFYEgYYAkeuOa9CtfH0FlFIviIR2gV5FjuolZoZQrYz04OMHglfmHzZOBwF1p1nbxfZIJYbeNJGgimASYpI25sDCjGXyDuOOmcAnFC3fVYLL7XOWtbyU+XHHGNxZwpL7lK5RgcFWHI+UEHjCW2hLR79aXVveQrNazxzQsMq8bhlP4irHevnDTvE9z4blfUYc2kb4S5Eb+XG8iqMMo2kEt1xzzu4GTXVQfHhEikN1oFwSrcMhKgjseVP9KadxWPZ6KKK6iAooooAKKKKAA0mBS0UAFFFFABRRRQAUUUUAFFFFABRRRQBHJCki4ZQR7141490X/hB9aXxZpaRva3UoivrJuFlznkfzOe9e01zvjLwoni7w/NpbXX2YyMrCXy9+0g+mRnjI696QHRGud8b3jWPg7U5I4nllkhMMaIMlmf5Rge2c/hXRVFPbw3MRjmjV0PYimTJXTR8nXehas4JXSb8HqcQNWcdF1lODp16v8AvQkfzr61Ogaaf+Xc/wDfbf40x/D2nMm1Y2T3DZP65rD2COiniasaapztJLuj5FjS9JdVRwUYq/H3T71NBE8citM5bHRQc5/OvqSPwNosDSNbwmFpTukMSopc+pwvNSnwhpxx8844x95f8Kl4dPQmdadrU0o+iPm+HxQ9lBHFb2iEqP8AWZG5vc59K7P4S60lx4+YzRrC9xZPFGFXG5gVbHHH3UP5V6yfBenM2WknbHTJXj9K0bDQrLT3DxKzyDgPIckD+VKlhYU5cy3OT2dRyTm7mivJzXK/EHS9J1jw/DY6xCJYZLkeWN5Vlk2PgrjqwG7jBzzkEZrrK5zxp4V/4S/R4dP+2/ZPLuFn3+VvzhWGMbhj73XPat583K+Xc6Fa+p85eI/hJqmnebdaFJ/almScw4xcJyeMdHA4yV5PPyjFefIwhmw6vuT5cZ+6Rx/P/Ir610n4f6lpvyy+JDdIPul7PDg/72/kfX86Z4i+E+jeKIy2ovtu+Nt5BEEl46buSHHGPmBIHAIrODqbSQ2l0PlhmlgjWWOSSFiuCeccg8K3XBB+nuc11Ok+Pr/SrgLHbQ3MMMewC4IOwA9VI+5wegP5kA16Gf2axxjxZgZyR/Z2fw/1vSnn9m9ZCzSeKQzEADGm7QMY7eZWjgmCkQReL9G1+1065EzaWbSQST22UiVUXONr4KEYYfKACQWypHI5bW/FEV032PS4PtSmSSKK5bfsfeeeAep/3sYJG3HJ7GH9nJoOV8WZPqdPP9Ja0I/gGqv8/iIPD5gmaH7GwV3BJGT52cYJ4BB561Hs2PmPE7u7u7x4zeCU+SfJQSDChlByuG75K5GCecHjGZreZIoFvbG4Rj92S3lYw7uP7ybNx4/HGa9hPwCnZog3izEcRJSNNO2hcnPA83A5A7dh7Yav7PFuokH/AAkCFX7GwIx+Uoq+W2wrnttFFFWSeYfHfVtR0bwJa3GmX11ZTvqCRmW2maNipjkOMqQcZA/KvnQeOvF//Q1a5/4MJf8A4qvf/wBoj/kntmB1/tOP/wBFS18xJjcN2duRnFJj6G9/wnXi/wD6GrXP/BhL/wDFUjeOvF/H/FVa5/4MJf8A4qsJsbm2525OM009RSGjof8AhOfF2P8Akatc/wDBhL/8VT4vHHi4tg+Kdb/8GEv/AMVXO0qkq3BwaCjqH8b+LPMwPFGtcf8AT/L/APFVA3jnxd5hx4p1vH/YQl/+KrC88liSOTTCckmkDOotfGvi1uW8Ua0frfy//FV9nV8LWwCwF8j0xmvumqRDCiiimIKKjllSJMs6r9TXHeKPF+o6Pq2nWmn2MM8Fykkss0jMDEI8F/lOOzLjJGSwHHGSwHa0lYur+IodH0y5v54ZmitkLyKoG7A6/wBM+n6V57rvxmtbfSft2mmKdHQNEPPjjLHOCMMd/wD4775pNAesyyxwrukkVF7ljgVy+pfEfwppF2tteaxEJi2wpGrOVPuFBIHv0rxrRdT1f4oXk1veeITYRqM+VCGVdgBJZn5zwD8ucHHbqNHxP4L8I+HfCF1YaW7XWuzqoiu5SS3yupby1XjHGMgcBuWx1Bnt2tSyRWaNG7IxkAypx2NYC3d2MD7XMQOpMhrd10Zso/8ArqP5GuOleY6pHbxuYo2jJLAjG7jjnqcZ4FbR2O/DRUoal0ancySvAl5MZEBDjzDkZ6fzH5VR1/Vr6y0m7lS8nXy4WKt55UlsYxnPHPT3rM2Sx6zI9vARIPmwZMqq7eOegyc/p14FVNQ1CK50bUotTjMkQtnkfauMKq549cdiM4PfNNNJo7ZYdct10PNpvGXiO20/Y2v6s06qxd/tshw+7kZDdgoH/Aq9T8G6nrEul3Md5qV1cNHOYopmnZiwVI1Jzn+9u/HPvXP+GPD+nWumWmtarKkdxJGG2tthQLkbQTwW6L1JHPTueui1zQxsih1OxG1dqIlxHxjoAM9Pp+VXJHJGMY6yRF4v16903wubqK+ukmlkjVCkrAglwx79Nu78q4jXPEXiKKH7KNY1GKe1EKyOl24Lny2GOD1yMn6itXXvEGlyPDdXFws0BTNlZYba5/56PtPflQGyu3cTntyETXPirWI7m3huFE12rZVSUVcYY7uTwAOvPPWtIpKLuVDlvsey6Tdaj/ZVmZ724kl8tfMYyHJOPr9a6vW8nTigkkjEh2Fo5CjAEEcEEEH6c+nNcjK5trKR0j3si/KoJyfyBP5An2PSuv1n/j0T/roP5Gud2ukc+MVrNeZxWla1e6fqh0LVb2drhy0lrO8pIuEz79GHcDIGeMAqo6IXVwf+W8v/AH0aytZ0dNZ08Qecbe4jdZba5UAtBKPusM9epBHcEjvUGha0+o20tvdLFFq1o/lXcCtwG7OuedjdVJ+nBBqtDhN77RcY/wBfJ/32aPtM/wDz3k/77NVQW3gO5Vc8dCT169vT39advUsdrA45xnPWiwyY3dxjiaU/8CNNa+mjyzXDLH6mQk/lTCM46c1Tnkjhzt/eSKOFGBzjPXoMgfmaVgNQXM5GRPIR6hzinC4nHJnkx6ljXPaLqEz6hd2NwEA/11sV6Mn3WXoOVO0nk8v1IxjI+J2qHS/CkbC6uLXzrpYvNt5vKYfI7Y3YPB2+lJger0UUVkM8j/aK/wCSf2H/AGFY/wD0VLXiOj/DHxdrthBfWGlF7SZd0cjzRpvGcZAZgf0r6Y+JGg23iHQ7K0uoWliS9Eu0MQAfLkAJwQT97+WeM1m6FapodglnIrC3DFUEbEBB2B5HToMdhnvUSlYasfOWs/DrxXoFs1xqOkSJCuS0kbrKFABJJ2EkDAPJ4/SuYI59+/tX2fex2txat9njknkJyg8w4Q9jyenHoa+ZvFnw9vdCle4sg91YEEpJwSMZyCB6DOeBgAngCpjIq3U4kYzzSnAPymnxW8s8yQwxSSSvwqINxb6AVtad4Q1rU1aSOyeOJc5aU7cH06Z/SrdhGDRX0Svwh8HXWi26i11KKcIN9zBKWZzjqVIYDPsvFeZ+PfhvN4SRr20uTcWDSbVEibZIwckBuxwByeD7VKkmUjgq++K+B/8APFffFWiZCHpWde6gI5BDEw8zq3PQVot0x6mvKPFPiOHRfFz2F1df2fdMDJbS3PMF5E5zglQfLZW3LkjkDP8AEKqO5D2OgTWpofFjadfTWojuEBs1Dnz2YAlsjpjg8nb0xWB8Vb8WPh+HULUyC6jkWINEWyqsyucgEAqTEoweeevY07uS8utRtLw2ubmNSqSwMjhlYdAQSSOfbvxVO81O9t8/abS9RR1dgkaj1OZHUelacqJcr7I7jTtah/sOw3qIZBbR7oghTYdoyNp5XHPB5+tY9y3hq1me9Ol6ek5JZpltk3EnrzjOTWFpcV9rEYlgityjAuhS5+0MwBwRtiG3Oev7ytbVfDX9kabZ6gbh5dRluIIbaRod0UDSyKgYplR/Fj+JhuGDgGjRE3kZdromnXev2thZaRBb62y3F8PLYRG2jJVAXK8ncGyMgkZIwO/oPh/wRpeiyfaHT7XfcZuZxubjGOpPIwOSSfp0rH8KXzv8UfFenXEiEW9rZiyQRgYi2sz4IHI3vk5JPI9K9A71m9zRGXr/APx4J/11H8jXC63eG0WLa5RXJyBnc2OcDj0BrutfGdPUf9NB/I1yl3YW16U86LzPLIIxkfy6j2PHtWkNj1cFJRjqefR+JLiHUWll2KCPKYW2IpCBjOPU9D7/AJCumimjvNHSXR5I5WONzn7/AD1zg59Bjjp19eI1iy8jUr6BAUiDs27ajKf4gPmXOcEcZ6+3NUtB1u60jXjOimW1lx5iKn8HHOMZz6nnoeTiuudK6TR6NV8rTS0LGt3lzpmpRsEFxdNklZI12uQcBuB1zk47YyTS3niTVJraJjOLe1uXBKxYQSDp8uDvHzAg9/QnNehzWmn6mtrd3ENpd25woMyK+S2MFcg87toxx174ArN8R+Gf7WlTyYcJDGreWMojcMAAR6cZBAGB15NSptaM5qnvyd9jlby58zRLjVIIk8xJXF0sJ8sx4XAbIAC5YZwODvI68i14Yu2XWomtWP2edFjAePO7ggk4xj2HI4Iye+r4S8OzRW99HeFZIZwVkXafnY43EqRg45B7c47YGhF4Vt9Ib7TZmeVUlDsu0SMy98EYJ+Yb/rnrnBUp30IpQUNGdRkDGAR/Dnt7j/Pr2rf8Si9/s1GsPs5lWUEpPuCuNp43DO05xzhuh45yMCM+YoOTgqCN/DY7ZBxjr3FP+KXixfB3hD+0RAZp5JhBbrxtEhRyC3IO0bTnHP8AOueWjRxYvoZU3iy306ZLfW4ZNKdvl86U74WJz92VflUHB5k2njgVyHiKz/4RnU7fxX4fFvJp1w+JsvtTcxwSH7I5xgngPtbIV3B5fw/8Wora3Eeu6fJczSlFe8YhmeMEh8gj6gAZHzHpyTYvfFngN7V5dE/tPS7y5wj28KJHC42sB50ZJiZDkE5DcfjQ2cVj1mwvodTsIr2BCYpE4Zm2lPmO4N02kN1HOCCCOCKSbXLW2uWtERp51O0pEFAGMZy2cDG7ocHg4z38Y0fxF/ZUE8E8SXFhKiO0+l3DR79gxJJ5TdXxs3KCnyjdgqWNemeG/EvhHVYre3sryGGbC+Xbzx+XJyueA33u/IznPX1Exm1crLeRAzSTJFj544AcEEY4wN5wSeVK/lUN3I8AVlQeWpBbC5w2Qeg4HJ654PuasrbXuplit41pZE/u/IVWkmI4LbmBAU4IwASQAc9qo65pV1pOmTalpF5IZLOJpXtbgh0mRQSVBxuRsZ2kEDPUYPDAz0k+x+IdH1A3zOksjW2TtKmN1AUKV45kER+hqL4vwTP4Mgmt22yW19FMpyBjhkzz7vVPWbme38PwalCkc8izRXotwNgIV93GeAFxyw9M85q78Sdc0y4+H84inhn+2GNooySpYCQNnb1wCBn0B96TYmew0UUVkM5fxxaR32nafbSxtJFJfIGAI4+V/m59Dg/h0PSsm4tNSvI7uMW0EkDgYeQMuR2G056c9hzjrkYtfE2/TT/DtrJIyqr3gQlmAA/dyHv16YxXIaXrcV1YmOQXSwwnCLaO8PHOMFWTOcdB6j8c5XuZyim3c7G2iurbTFsElBuzku8EfCDOcbTkL1wAfqM4OMXW47fTdAmubi7Q5LSO6naFcA9BnAAKtkDPT2NXDZ28awusmoMwIPzXs+AO+75zn0x6n8a8l+JnisTzy6TZr5bFh9pdQFY7eAGI6nv+WOME5O7djWMEtibwQLDXG1eOwVLd5Loyyog/ePH8pB5HCkg/LyAfqM99Y2EOnXiLFaQJF5ZlmnlwJFjAPDd8fKOSAMHp1NeA+HLma01hfJd1aQEDaSDwQeMEYPccjmvfNLu7tT9slaGeeSAQGRnMbqN5Y4YZXA3cDZk4GWNXbUmatsaSatDBEk1hcW6W7sys24KQcklgpyCSc5475yc1B4x0KLxHoDx37SzxqgIijC8OP+Wg4zuAJ7kcHIPNXHGlC1Mh0uWAxyjLyQCYyjOSwEZZu/cDHoASafNDbaktndSBU8gq6RbJFZCMHjcFI/75HAGRSdkEOdK71PmzxR4Kv/DYFxkT2jEYmUYKk/3h/Ijg+2cD7QYkLkV85/EjxDp9tFe2QjEjTRPGtuQdxJB/ecjG1eCCM8gY7lfo2tIO6Kfoc14zv9dsNE87QrBryXePNEeDIseCSyKfvHIXjuCcc188+LLC81UL4hvbTUoLeEiOW9mt2kLENt5GcDDHHzMuQRgHGK+q8Vz3jnRP+Ei8D6zpSwedLPav5Me7bmVRuj5/3wv9eKsRi/CWeS7+H2nT+but/wB4kCfKSqK5XDEAZOVY5wOG9s1T+Nek/wBo/DPUXWNpJbRkukUdtrAMT/wAtWJ+zvqX2jwZf6e8xeS0vWIQnOxHVSPzYPXpviLThq3h/UNNLiMXdtJb7yPu71K5/WmB5f8AAHUPtXg2aBwP9FvXVBnOAwDZ/NmrtPiCCvg/ULiM4ktEF7H7tCwlUfmn6145+z9fCDVtXsHcq7pHIqHttJDcf8CWvbfFN3p9t4fu5dUliisREyTtI3GDwR6nOcYHcjHNMk5q2Bt/jrBcmP5L3QXhDqOrLMrEn8No/KvSwa8w+Gt43ia/t9VBMkWk6eNOknYAie5cRPLtOc4TYozj5vM4JAyfUKTGjL14ZsY+QP3o6/Q1zTj5TzkHt2NdLr3/AB4p/wBdR/I1zLyIhClhvOSBnritYao9LDfwzkvGdlaRwjUWnkhuNyhShAU+hPQ9AwznuK8+LwOWieaVDIMkbAAxxgncecHjB579a7zxsGVLWQFljG8bjlQpOOT/AJ7etef2Gny6nq8EceEiY/PgHk7sHnGcYPfsG6fdrtpv3LnqrSkjXtfFGoaLFBpiMbjyZDLJtxu2AH5eRxzznHPODmtM/Ea5WKZoNMWOKNW/10j79/Ixkj5jwPzFZN7CkFtfl1ZfL1Bba1wMBUUYyOOOGBJHXOcZrNMUF+qSmNfOQ7g/que/vwfxHTmmoRkrmcI8+q3Oy0L4gWTL5dzbSRAMS8hJbGSfr/PvXbWd9bahAs9tOs0YOQynp9eBzXjTWJR/MVzkHryrHnoTnP8AXoDnrXZeDtIvor5L4CNLR927gAvxjkD3GaidJJXuXPDpRbkzvc7hkEFawvj9PDbeBbCSe2WdP7UjGxiR/wAspeRjv9c1vDPBCj65rS8caHpGv6LDba3AJrWK4EwUysgDBWGcqQTwTxXHNao8bF9D4/0/SdZ8T38i2FlPdzMxaRkHCk/3mPA/E16jo/wIklt1l1nVDFMT80NsA23npuPX8vzr1jTFW2iaC0iggsI8JbxRQ7BGBkNnnB+YHsO/Xqbckvl7eHeRh97aCPbP48fjQo3OK9tWeP3fwetbO8jbSdYuIpIvmHmqku49sLxwSGBDZ69+lZeqeHtZ03SotNt0SdhIW/sy6iSRIQwyfKZslQcMQQ2cCQdY2ZvX7N1jjScQRxLKzgSGQSFsO2MHJyDkkc8cjA4zj+LmtZtNMk0gh1OIbrdy20kjDbC3TnaCOu0gMAStDjbyGmnsZfhW/sNP0+0lbxFd6RPHEDdWOqA+QZMbfkMmBtypwEfnGOMGtmL4keHdQnutN/tC0aXDIrJIWRwSFUcqCzNk8KGAxye9ZCXsupaZBqV2vlo+IJHkwMMHG5dpB2E45X2GGYfPXP65oHhlFg+22tujSMdrIrgYwAR8uDgfLjr9Bmleyuyo05TklFXZ1OrI0c0MV1ArBsCJUQHzAcK3GOQBzxjIAOARzx7aFYadqj6nq8BueNzWx5UdwScHcGI7YGCwyQeKuiXkNlObHTr3UfsfSO0ursLFMCeRgjbGeQevOCOMim6vf2Omlr3XZVvtTV3UadD/AKuMbQcOTjaBkr/e4xwBUKalszavhatB8tRWPqOiiikc55P+0FuHgKxZc5GpxnIHT91LXmngvXdO+yrb3euXlhOsexi8RmQMCcFdpyvbquOOp616b+0AwXwHY7gCDqcYOf8ArlL7GvnRJ0+VW3bV+6vp+tRJ9DWNJTR6T4m8eyWFu1to+ry3kzN81y8GxFXGPlVmZs9PQDPfIx5rJM9xI0szs7sdzM5yST1NWw1pK67ygwMYAx/UfzqaPTraZWeK4jLKCRGu8n9Aw/Ws9DRUrbGarGORZY22yIQyt6H1r0DSPGVyLaOSS2MaE4WcFiokB+6oBwcnB7da5aTw1crDGUeOaSXiKOCWKVifQhX3A/8AAas2kuveErhljE1tLKmJIXiIBGO4lXafyNUmRUpOSPYNJ8R2wtgPtFuIwoOIgz87iDjuT/s4yOCQMjNDxh49t9JtHitXjmupAQiK2SPdvTnt/Pt5prPi2+1S3Ft9jsoCq5Z7O2QO3QklxkqT324HtXMiJ2RmIPy9flP6fpQ9TOFLl3Kmp3d3fXst3dyvLLMdzOec/wD6q+7q+Fbk+WgKEkj7wP8AhX3VWiE9wpG6UtFMR5lq/h3WfB3iS/8AFnhOzW+hv1LalpIba0jjJEsTd2yT8uCTuOOSNuPqfx6sbOOa2fw3q66nEQslrMFRUPcFwWI7/wAPavZcCk2r6D8qAPjHTtf1s+M7zU/DkAs7+9kk22tvH5hIZtxVVYNzkDt9B2rv7H4Z+OvH95Fd+KtQns7HO/bdMfMUHdwkIwEOVGeF4OeelfR+AOwpcU7isZmg6JZeHdGtdI06Py7W1j2ICck85LE+pJJPuTWnRgelFIZl69/x4p1/1g6A+hryHV764uNZnR4zmM/6NIDgxtjpxjjcpzn1HX+H1TxddrZaMsrFf9aAAzYBOD35/kfpXi80bCSa5SNnSWVpPmUOG3ElhwAcEcbuCS2M4ANduHVo8zPYy+F4XsdZfu2rWlvYLGBcXOCXK5WIAKWI6E8MB269RTNJ8N2WhyGVnWSXhY5GULtHXjOeevP1985dxr81hYJHgyTxAoJTE+OABuyAQSck4yOCcmsieRnAnuIZ7sEkmQy8J0H/ACz6DIJ5P41UYykmnsdjhPlcVsP8fmWS9APEMaKQwwQwJ6n06tz7VQ0HR5bnUreJIMIrjcE5CoAMknsfkwD7V2mo6LZ3K6RaTqd7koOrF41UsQTycenPetzTdHtNMRktIBEGO5myWJxzyTzx2Huap1FGIvaQhG63GQaNp9tc/aYbWOOVh1UcfgOgPHUetaC4QYAx6c1Xur61so91zcxQBuQCwGecfjz/ACpljqVrfxmazuY51xyUbP49sD8KwtJ6s5m5PVlxR/eA/Cug8QyxRWMQlmji3yhFMjABmIOAPf6Z+lYBboQAfp0p3xQ0u71bwbNDZLA06M0ipNAsu/EbjaoYHDHOARzWUt1Y4MX0sc5NqFsmqvaWWp2xm3nzmmuP3lsxKqsQTqCWyRnuQDneM8P4g1e7u7uS2nmkMVvIy4ZslmBI3HAAz16YGOgxXk41ONngeS2XfGMNIAOSDkNjoGPQnkH0zzWtD4u8s+XLbKYhgII2I8tMcLg8nAAHXPuetehl2Io0qjlVR5WKp1JxSgzv9I1n+x2upnl2RNbu2TjG5VLJweM5AH0Y+tQWya34wmlu7aMtZrKUaeVtiODjrkkgAxg7FzkN2H3vPtR8Ry6jGLaOIRRscsWPLY/kM8/1r0r4c+KLV7EaRcSwwXCtutyZMefk/j83I4z/ACrzuIMeoxdXDxvb+r2NsvoSUeSoyWLR/FOgW+o3cd1p7wShZJ7bLFcpgiRdwHzDABBwrDg9qyNYxq1vFcaZbTSW8ckpeQDhjlc4P8XzbuRx6Y5r02WeBdkEhVvNyioFLZ45yOSAB1JwAO4ry/X/ABbaG6FzaXymCB8W0UOAFOBluOg/qB2zXgZTja+NhKFZW63tp6HrKawlWNWGtjn8Yx3z0/p+tMvda2M5PlzXqbUE7FTsUKABuIPYgcYK7Md8DD1K/S8uWk86fbIxyg4Gf8n/ADmqCRyXc6W9uju7thIlG4sx6AAdycCvWpUOR7nTmearFw5IxskfeVFFFaniHJ/EHwWfHWgwaYNR+weVdLceZ5AlzhXXbjcP7+c57V5v/wAM5jv4pH4adj/2rXulFKyGpNbHhf8AwzkgbK+KSPrYZ/8AalPH7O5Gf+Kq/wDKf/8AbK9xopciK9pJdTxUfAKdYREPF8gQHIUWOAD9PMp6fAe6ifdF4uMZ9U04KfzEma9noo5EP2s+54u3wEkdiX8UK5bqX0/cT+JlNMP7PqkHHiXBPcWPP/oyva6KOVB7SXc8Nl/Z181Cp8Vde50/JH/kWvcqKKaViG7hRRRTEFFFFABRRRQAUUUUAZHiHQk8QWEVq8oj8uUSglN4yAR0yP71ctD8MQl59ol1ffxtKLahQFwRgDccda9AorRVZqPKnodFPFVqceWDsvkeen4WW/niZdQVJByHW2+bOAOfm5HGMVai+G9vb3a3UN9sk2bGTyMxt6kjdn1713FFNVppWuU8bXe8vyOXfwpdmEGPVIkuQxxKLTIK7cYK789cHqKoX3gnWLuxlhi8SrazShVaSKyOABvztBk+UncvIOfl9+O3orOUnJ3ZH1mr3POL74VyXhtydefMMXlBnhcscksTlZF/iZj6Y2jtk6WgfD1NCinA1WW5lm275JIlHTOMYPuepNdrRWjrTatcPrNW1rmJ/wAI/wDNk3Of+2f/ANetG+s/tsCx+Zsw27OM54Ix+tWqKzcmzOdSU/iPG/FPwBtPEGuTalaa5/Z/n/PLELPzAXPVh864z/PmsX/hmf8A6m7/AMpv/wBtr36ii7IPAR+zOR08Xf8AlN/+21Mn7OEsUiyx+MWWZSGWQaedykdCD5vB4Fe8UUnqFzx7UvgnqWqMZJ/FtuJnh8mWZdGQSSDuS3mZBI4JGMjg1hn9mjJz/wAJdz/2Df8A7bXvtFKKUVZDbbPAh+zRg5/4S7P103/7bXceDvhBpHhBRPHP9r1HnN3LDgrkYwgydoxnuTyeccV6LRVXEFFFFIAttCQAsiQotwsxujAwSy0JzgD/2QoK'img_data = base64.b64decode(url) 返回的是二进制数据print(type(img_data))fn = open('code.png','wb')fn.write(img_data)fn.close()'''我们打开了一个有base64加密的图片数据''' 本篇文章为转载内容。原文链接：https://blog.csdn.net/httpsssss/article/details/116136614。 该文由互联网用户投稿提供，文中观点代表作者本人意见，并不代表本站的立场。 作为信息平台，本站仅提供文章转载服务，并不拥有其所有权，也不对文章内容的真实性、准确性和合法性承担责任。 如发现本文存在侵权、违法、违规或事实不符的情况，请及时联系我们，我们将第一时间进行核实并删除相应内容。

...用导致的一切后果，由使用者承担责任。

...用导致的一切后果，由使用者承担责任。

...用导致的一切后果，由使用者承担责任。

...用导致的一切后果，由使用者承担责任。

...用导致的一切后果，由使用者承担责任。

...用导致的一切后果，由使用者承担责任。

...用导致的一切后果，由使用者承担责任。

...用导致的一切后果，由使用者承担责任。

...用导致的一切后果，由使用者承担责任。

...用导致的一切后果，由使用者承担责任。

...用导致的一切后果，由使用者承担责任。

...用导致的一切后果，由使用者承担责任。

...用导致的一切后果，由使用者承担责任。

...用导致的一切后果，由使用者承担责任。

...用导致的一切后果，由使用者承担责任。