xmind格式学习笔记下载链接：

Windows上运行嘚任何32位JVM（无论机器上CPU的个数是多少）以及单CPU机器（不论是什么操作系统）上运行的任何32位JVM，都是client类机器所有其他机器（包括所有64位JVM）都被认为是Server类。

  借助性能分析来优化代码重点关注性能分析中最耗时的操作

  利用奥卡姆剃刀原则诊断性能问题

  为应用中最常用的操作編写简单算法。

 原则1：测试真实应用

-options选项能够列出所有的选项最常用的一项是-gcutil，它能够输出消耗在GC上的时间以及每个GC区域使用的百分仳。其他的选择能够以KB为代为输出各GC空间的大小

   2.应该花些心思来确定，算法中的递归任务合适结束最为合适创建太多的任务会降低性能，但如果任务太少而任务所需的执行时间又长短不一，也会降低性能

   3.Java8中使用了自动并行化的特性会用到一个公共的ForkJoinPoll实例我们可能需偠根据实际情况调整这个实例的默认线程大小

   同步代码堆性能有两方面的影响。其一应用在同步块上所花的时间会影响该应用的可伸缩性。第二获取同步锁需要一些CPU周期，所以也会影响性能

    1.线程同步有两个性能方面的代价：限制了应用的可伸缩性，以及获取锁是有开銷的

    2.同步的内存语义、基于CAS的设置和volatile关键字对性能可能会有很大影响，特别是在有很多寄存器的大型机上

   在通常情况下，在比较基于CAS嘚设施和传统的同步时可以使用如下的指导原则

    1.如果访问的是不存在竞争的资源，那么基于CAS的保护要稍快于传统的同步（虽然完全不使鼡保护会更快）

    2.如果访问的资源存在轻度或适度的竞争那么基于CAS的保护要快于传统的同步（而且往往是快得多）

    3.随着所访问的资源的竞爭越来越剧烈，在某一时刻传统的同步就会成为更高效的选择。在实践中这只会出现在运行着大量线程的非常大型的机器上

    4.当被保护嘚值有多个读取，但不会写入时基于CSA的保护不会收到竞争的影响

    1.避免对同步对象的竞争，是缓解同步对性能影响的有效方式之一

    2.线程局蔀变量不会受竞争之苦；对于保存实际不需要在多个线程间共享的同步对象它们非常理想。

    3.对于确实需要共享的对象基于CAS的工具也是避免传统的同步方式之一

Instruction，CPI）的相关信息；如果某个循环内的一条简单指令的CPI非常高可能预示着代码正在等待将目标内存的信息重新加載到CPU缓存中

    2.伪共享很难检测。如果某个循环看上去非常耗时可以检查该代码，看看是否与伪共享出现时的模式相匹配

    3.最好通过将数据迻到局部变量中、稍后再保存来避免伪共享。作为一种替代方案有时可以使用填充将冲突的变量移到不同的缓存行中。

   每个线程都有一個原生栈操作系统用它来保存该线程的调用栈信息

     3.在Unix风格的系统上，用户创建的进程数已经达到了配额限制这方面单独的线程会被看莋一个进程。

    在32位的JVM上可以减少线程栈大小，以便在4GB进程空间限制的条件下稍稍增加堆可以使用的内存。

   偏向锁背后的理论依据是洳果一个线程最近用到了某个锁，那么线程下一次执行由同一把锁保护的代码所需的数据可能仍然保存在处理器的缓存中

   在处理同步锁的競争问题时JVM有两种选择。对于想要获得锁而陷入阻塞的线程可以让它进入忙循环，执行一些指令然后再次检查这个锁。也可以把这個线程放入一个队列在锁可用时通知它（使得CPU可供其他线程使用）

   操作系统会为机器上运行的每个线程计算一个“当前”（current）优先级。當前优先级会考虑Java指派的优先级但是还会考虑很多其他的因素，其中最重要的一个是：自线程上次运行到现在所持续的时间这可以确保所有的线程都有机会在某个时间点运行。不管优先级高低没有线程会一直处于“饥饿”状态，等待CPU

   在某种程度上，可以通过将任务指派给不同的线程池并修改那些池的大小来解决

  在对应用中的线程和同步的效率作性能分析时，有两点需要注意：总的线程数（既不能呔大也不能太小）和线程花在等待锁或其他资源上的时间

    可以深入到JFR捕获的事件中，病寻找那些引发线程阻塞的事件（比如等待获取某個Monitor或是等待读写Socket，不过写的情况比较少见）

    jstack、jcmd和其他工具可以提供虚拟机中每个线程状态相关的信息包括线程是在运行、等待锁还是等待I/O等

    在查看线程栈时，有两点需要注意第一，JVM只能在特定的位置（safepoint安全点）转储一个线程的栈。第二每次只能针对一个线程转储絀栈信息，所以可能会看到彼此冲突的信息

    1.利用系统提供的线程基本信息可以对正在运行的线程的数目有个大致了解

    2.就性能分析而言，當线程阻塞在某个资源或I/O上时能够看到线程的相关细节就显得比较重要

    2.外部网络相对内部网络来说仍然是慢的。限制应用缩写的数据量會取得很好的性能

    HTTP会话数据通常存活时间很长所以很容易塞满堆内存，也常常容易导致GC运行太频繁的问题

    一旦你更改了会话状态中的对潒值都应该调用setAttribute(),确保你的应用服务器配置成只复制更改的数据

    2.尽可能少地在会话状态中保留数据，尽可能缩短会话的有效期以减少会話状态对垃圾收集的影响。

    3.仔细查看应用服务器的调优规范将非活跃的会话数据移出堆

    4.开启会话高可用时，需要确保将应用服务器配置荿只在状态属性变化时进行会话复制

  应用服务器通常不只有一个线程池

  应用服务器中的线程池可以依据不同的请求量分成若干优先级

   因為EJB对象创建（和销毁）的代价很高，所以它们通常保存在对象池中

   只有在应用服务器池中还有可用的EJB对象时，性能才会提高所以必须將应用服务器中的EJB对象数配置成应用同时使用的EJB数。

    1.EJB池是对象池的典型范例：初始化代价高数量相对较少，所以池化更为有效

    2.通常来說，EJB池的大小包括稳定值和最大值对于特定的环境，两种值都需要调优但从长期来看，为了降低对垃圾收集器的影响应该更注重稳萣值的调优。

   与会话关联的状态Bean并没有保存在EJB池中而是保存在EJB缓存中。因此必须对EJB缓存进行调优，以便容纳应用中同时活跃的最大会話量

   和HTML数据一样，程序中的数据也能从减少空格和压缩中获得巨大的益处

   依据程序的上下文和输出结果这个过程被称为编组（marshal）或解析。反过来——从数据生成XML或JSON串——则被称为解组（unmarshal）

     解析器遍查输入数据中的标识符当发现标识符时则回调相应对象上的方法。

     输入數据被转换成文档风格的对象以便程序在查找数据片段时可以遍历。

    2.虽然这些技术给开发人员提供了很多功能但数据处理本身的代价吔增加了。不要因此影响你在应用选择正确处理数据的方法

    3.查找解析器工程的算法非常好使；如果可能的话应该通过系统属性直接指定笁厂而不是用现有的实现。

    4.在不同的时间点上最快的解析器实现的赢家可能会不同。适当的时候应该从备选的解析器查找。

   解析器可依据一个schema（意为“模式”）对XML数据进行验证拒绝语法不正确的文档——指缺少某些必要的信息，或者包含了不该有的信息的文档

    1.如果業务需要进行schema验证，那就用它只是要留意，验证对解散数据的性能会带来显著的损耗

    2.过滤模型数据比构造默认模型要花费更多的世界，但对于长时间运行或者很大的文档来说仍然是值得的。

   处理文本数据的最后一种选择是在解析相关的数据之后创建一组Java类实例

  Java进程間交换数据，通常就是发送序列化后的对象状态

   2.将变量标记为transient可以加快序列化，并减少传输的数据量这些做法都可以极大地提高性能，除非接收方重建数据需要花费很长时间

   4.通常在序列化时进行压缩都有益处，即使数据不在慢速网络上传输

   传输的数据量应该尽量小無论是压缩或去冗，或其他技术

    2.最合适的驱动程序往往依特定的部署环境而有所不同对同样的应用程序，在一个部署环境中可能要使用JDBC驅动程序在另一个部署环境中则要采用不同的JDBC驱动程序，才能有更好的性能

    1.Java应用程序通常都会重复地运行同样的SQL语句这些情况下，重鼡预处理语句池能极大地提升程序的性能

    3.预处理语句会消耗大量的堆空间。我们需要仔细调优语句池的大小避免由于对大量大型对象池化而引起GC方面的问题

   对于连接池而言，首要的原则是应用的每个线程都持有一个连接对应用服务器而言，则是初始时将线程池和连接池的大小设置为同一值对单一的应用程序，则是依据应用程序创建的线程数调整连接池的大小

    1.数据库连接对象初始化的代价是昂贵的。所以在Java语言中它们通常都会采用池技术进行管理——要么是通过JDBC驱动程序自身管理，要么在Java EE和JPA框架中进行管理

    2.跟其他的对象池一样，对连接池的调优也是非常重要的我们需要确保连接池不会对垃圾收集造成负面的影响。为了达到这个目标调优连接池，避免堆数据庫自身的性能产生负面影响也是非常有必要的

     这是最昂贵的事务模式；它要求在事务进行期间，事务涉及的所有数据都被锁定通过主鍵访问数据以及通过WHERE子句访问数据都属于这种情况；使用WHERE子句时，表被锁定避免事务进行期间有新的满足WHERE语句的记录被加入。序列化事務每次查询时看到的数据都是一样的

     这种模式下要求事务进行期间所有访问的数据都被锁定。不过其他的事务可以随时在表中插入新嘚行。这种模式下可能会发生“幻读”（phantom read）即事务再次执行带有WHERE子句的查询语句时，第二次可能会得到不同的数据

     使用这种模式时事務运行期间只有正在写入的行会被锁。这种模式肯呢个会发生“不可重复读”（nonrepeatable read）,即在事务进行中一个时间点读到的数据到另一个时间點再次读取时，就变得完全不同了

     这是代价最低的事务模式事务运行期间不会施加任何锁，因此一个事务可以同时读取另一个事务写入（但尚未提交）的数据这就是著名的“脏读”（dirty read）；由于首次的事务可能会回滚（意味着写入操作实际并未发生），因此可能会导致一系列的问题因为一旦发生这种情况，第二次的事务就是对非法数据进行操作

   如果两个数据源之间极少有机会发生碰撞，则使用乐观锁笁作是最好的

    1.事务会从两个方法影响应用程序的性能：事务提交是非常昂贵的与事务相关的锁机制会限制数据库的扩展性

    2.这两个方面的效果是相互制约的：为了提交事务而等待太长时间会增大事务相关锁的持有时间。尤其是对严格语义的事务来说平衡的方式是使用更多哽频繁的提交来取代长时间地持有锁

   如果next()方法的性能是不是地非常慢（或者结果集的首次查询方法性能很差），你可能就需要考虑增大提取缓冲区的大小

    1.需要查询处理大量数据的应用程序应该考虑增大数据提取缓冲区的大小

    2.我们总是面临着一个取舍即在应用程序中载入大量的数据（直接导致垃圾收集器面临巨大的压力），还是频繁地进行数据库调用每次获取数据集的一部分。

  为JPA特别定制的字节码处理方法并不存在通常情况下，这是作为编译过程的一部分完成的——实体类完成编译后（在它们被载入到JAR文件、或者由JVM开始运行之前）它們被传递给与具体实现相关的后处理器（postprocessor），对字节码进行“增强”最终生成一个替换类，这个类按照需要进行了优化

API,JTA）实现的组成部汾这种设计提供了两种实现事务的选择：可以由应用服务器来处理边界（使用容器管理事务，即Container Managed TransactionsCMT），或者由应用程序通过编程显式地控制事务边界（使用用户管理事务即User-Managed Transaction，UMT）

    XA事务是使用了多个数据库资源或者同时使用了数据库及其他事务资源（比如JMS）的事务

    3.还有另┅种替代方案，即可以按照应用程序的事务需要将JPA划分到不同的方法中处理

    优化数据库写操作性能的一个比较通用的方式是只更新那些巳经变化的字段。

    1.JPA应用和JDBC应用一样受益于对数据库写操作的次数限制（有时还需要权衡是否持有事务锁）

    查询实体时，被声明为延迟载叺的字段会从查询载入数据的SQL语句中益处

    我们很少在基本类型的简单列上使用该声明，不过如果实体包含大型的BLOB或者CLOB对象就需要考虑昰否使用这种声明了。

     使用提取组我们可以制定哪些延迟载入的字段可以作为一个群组，一旦这个群组中的一个成员被访问整个群组嘟会被载入。

Relationship）而言无论它们被注解为主动载入还是延迟载入，都可以使用联合查询如果join应用于延迟载入关系的实体，且注释为延迟載入的实体满足查询条件这部分实体也汇总数据库中返回，且这部分实体在将来使用时不需要再次访问数据库。

    JPA的实现几乎都结合语呴缓存池使用了带绑定参数的预处理语句没有任何规定禁止JPA实现使用类似匿名或即时查询应用的逻辑，只不过这种情况实现的难度会更夶而JPA实现可能仅仅是每次创建一个新的语句（即一个Statement对象）

    2.JPA实体中，如果一个大型字段（比如BLOB类型的字段）很少被使用就应该延迟载叺

    3.JPA实体之间存在关系时，相关的数据可以主动载入或者延迟载入具体的选择取决于应用程序的需要

    4.采用主动载入关系时，可以使用命名查询生成一个使用JOIN的SQL语句应注意的是，这会影响JPA缓存因此并不总是最好的注意

   实体管理器提交事务时，本地缓存中的所有数据会合并箌全局缓存中全局缓存对应用程序的所有实体管理器而言是共享的。全局缓存也被称为二级缓存（L2 Cache）或者是二层缓存（Second-Level

   一个替代的方案昰使用软引用或者弱引用作为JPA实现的L2缓存

    2.L2缓存不会对查询返回的实体进行缓存。长期来看这种方式有利于避免查询

    3.除非使用的JPA实现支歭查询缓存，否则使用JOIN查询的效果通常会对程序的性能造成负面的效果因为这种操作没有充分利用L2缓存

   JPA规范并未直接定义只读实体，但昰很多JPA供应商提供了该功能通常情况下，只读实体比（默认的）读写实体性能更好因为JPA实现很明确地知道它不需要跟踪实体状态，不必再事务中注册实体也不必对实体上锁，等待

EE容器中支持只读实体的事务：可以在事务之外运行一个通过@TransactionAttributeType.SUPPORTS注释的业务方法（假定该方法調用的同时没有事务在运行）

  合理调优访问数据库的JDBC和JPA是影响中间层应用性能最重要的因素之一请牢记下面的最佳实践

   优化应用使用的SQL語句。对于JDBC应用这都是一些基本、标准的SQL命令。对于JPA应用你还需要考虑L2缓存的影响

   合理地设置事务的范围：由于锁在整个事务期间都需要保持，所以在不影响应用程序扩展性的前提下尽可能把事务的范围设置得大一些

  InputStream.read()和OutputStream.write()方法操作的是一个字符。由于所访问的资源不同这些方法有可能非常慢。而在fileInputStream上调用read()方法更是慢点难以形容：每次调用该方法，都要进入内核去取一个字节的数据。在大多数操作系统上内核都会缓冲I/O，因此很幸运，该场景不会在每次调用read()方法时触发一次磁盘读取操作但是这种缓存保存在内核中，而非应用中这就意味着每次读取一个字节时，每个方法调用还是会涉及一次代价高昂的系统调用

  写数据也是如此：使用write()方法向fileOutputStream发送一个字节，也需要一次系统调用将该字节存储到内核缓冲区中。最后（当问及关闭或者刷新时）内核会把缓冲区中的内容写入磁盘。

  当在字节和字苻之间转换时操作尽可能大的一段数据，性能最佳如果提供给编解码器的是单个的字节或字符，性能会很差

   1,围绕缓冲式I/O有一些很常见嘚问题这是由简单输入输出流类的默认实现引发的。

   2.文件和Socket的I/O必须正确地缓冲对于像压缩和字符串编码等内部操作，也是如此

  自定义嘚类加载器默认是不支持并行的如果希望自己的类加载器也能并行使用，必须采取一些措施措施总共分为两步

   首先，确保类加载器的層次结构中没有任何回环

   第二在定义类加载器类时，在静态初始化部分将其注册为可以并行的

  在编写类加载器时建议重写findClass()方法。如果洎定义的类加载器重写的是loadClass方法而非findClass()方法，则一定要确保在每个类加载器实例内对于每个类名，defineClass()方法只调用一次

   1.在存在多个类加载的複杂应用（特别是应用服务器）中让这些类加载器支持并行，可以解决系统类加载器或者启动类加载器上的瓶颈问题

   3.SecureRandom类表现出的性能也昰随意的和完全随机的在对用到这个类的代码做性能测试时，一定要认真规划

  如果想编写尽可能快的代码要避免使用JNI

  尽可能避免从Java调鼡C。跨JNI边界（边界是描述跨语言调用的术语）成本非常高这是因为，调用一个现有的C库首先需要一些胶水代码需要花时间通过胶水代碼创建新的、粗粒度的接口，一下子要多次进入C库

  当有数组被固定在内存中时，垃圾收集器就无法运行——所以JNI代码中代价最高的错误の一就是在长期运行的代码中固定了一个字符串或数组

   3.使用数组或字符串的JNI代码必须固定这些对象；为避免影响垃圾收集器应该限制固萣对象的时间

  基本上，代码仅应该通过抛出异常来说明发生了意料之外的情况遵循良好的代码设计原则，意味着Java代码不会因异常处理而變慢

  异常会涉及获取该异常发生时的栈轨迹信息这一操作代价可能会很高，特别是在栈轨迹很深时

   1.处理异常的代价未必会很高不过还昰应该在适合的时候才用

   3.对于会频繁创建的系统异常，JVM会将栈上的性能损失优化掉

   4.关闭异常中的栈轨迹信息有时可以提高性能，不过这個过程往往会丢失一些关键信息

   没有必要在堆中为所有这些对象都分配空间；因为字符串是不可变的所以重用现有的字符串往往更好

   Java的芓符串采用的是UTF-16编码，而其他地方多是使用其他编码所以将字符串编码到不同字符集的操作很常见。对于Charset类的encode()和decode()方法而言如果一次只處理一个或几个字符，它们会非常慢；无比完整缓存一些数据再进行处理

   在编码静态字符串（来自JSP文件等地方）时，Java EE应用服务器往往会特殊处理

  永远不要使用连接来构造字符串除非能在逻辑意义上的一行代码内完成；也不要在循环内使用字符串连接，除非连接后的字符串不会用于下一次循环迭代

  对于应用日志，需要记住3个基本原则

   3.在向代码引入日志时应该注意，很容易编写出来意想不到的副作用的ㄖ志代码即使这个日志并没有开启。

   1.为了帮助用户找出问题代码应该包含大量日志，但是这些日志默认都应该是关闭的

   2.如果Logger实例的参數需要调用方法或者分配对象那么在调用该实例之前，不要忘了测试日志级别

   1.仔细考虑如何访问集合并为其选择恰当的同步类型。不過在不存在竞争的条件下访问使用了内存保护的集合（特别是使用了基于CAS的保护的集合），性能损失会极小有时候，保证安全性才是仩策

   2.设定集合的大小对性能影响很大：集合太大会使得垃圾收集器变慢，集合太小又会导致大量的大小调整与复制

  AggressiveOpts标志（默认为false）会影响一些基本Java操作的行为。其目标是实验性地引入一些优化；随着时间的推移原来由这个标志启用的优化有望成为JVM的默认设置

   1.AggressiveOpts标志会在┅些基本的类中开启某些优化。大多数情况下这些类要快于它们所替代的类，不过可能有意想不到的副作用

  在JDK8中Lambda表达式的代码会创建┅个静态方法，这个方法通过一个特殊的辅助类来调用而匿名类是一个真正的Java类，有单独的class文件并通过类加载器加载

   1.如果要在Lamabda表达式囷匿名类之间做出选择，则应该从方便编程的角度出发因为性能上没什么差别

   2.Lambda表达式并没有实现为类，所以有个例外情况即当类加载荇为对性能影响很大时，Lambda表达式略胜一筹

 流和过滤器的性能

   1.过滤器因为支持在迭代过程中结束处理所以有很大的性能优势

   2.即使都要处理整个数据集，一个过滤器还是要比一个迭代器稍微快些

   3.多个过滤器有些开销所以要确保编写好用的过滤器

搜索架构的探索之当前现状

如上圖是蘑菇街当前搜索架构，分为在线和离线两部分在线部分主要职责是处理在线的搜索请求。离线部分的主要职责是处理数据流

如仩图，是整个在线请求链路主要分为topn->qr->引擎->精排->透出五个环节。

第一步请求首先进入topn系统，做ab配置/业务请求链路配置

第二步，请求进叺QR改写系统做切词同义词扩展，类目相关性插件化等。

第三步进入UPS用户个性化数据存储系统。

第四步投放层得到UPS和QR两部分的数据後，放入搜索引擎做召回搜索主要会经过一轮海选，海选的依据是文本相关性和商品质量这样做是为确保召回的商品质量大致可靠。の后会经过多轮初选过程中会应用到更复杂的算法模型，对海选的结果进行排序搜索引擎得到粗排的结果约千级别。

第五步粗排结果进入到精排系统，精排系统主要通过算法做个性化排序、实时预测，精排和引擎类似也支持多轮排序。经过精排系统之后最终把結果透出给业务层。

如上图左侧红色框内是蘑菇街统一引擎系统，包含用户个性化存储系统、精排存储、商品引擎、广告引擎等由于這样的形式维护成本特别高，故做了右图这个统一的Zindex内核架构这个架构的最底层是共享内存分配器，再上层是可支持不同数据结构的各種引擎再上层是索引管理。基于这个架构不同的引擎可根据各自需求去创建自己的索引。

跟这个架构相关的就是我们的运维平台，昰基于公司Docker虚拟化技术做的一个运维平台能够非常快的支持索引创建，包括创建之后整个索引数据的管理还有就是排序平台，用来提供算法配置变更服务

搜索架构离线部分的数据流程

如上图，是离线的数据流程的情况主要职责是数据流的处理，完整的索引数据分为算法数据和业务数据

算法数据参与排序，整个链路从最前端ACM打点、再落到整个数据仓库、经过清洗之后在数据平台上跑训练脚本，得絀的特征导到特征平台再同步到线上。

业务数据的主要来源就是DBDB中主要存储商品、店铺之间的数据，业务变更主要基于mysql bin-log事件监听变哽之后做全量和增量。全量每天定时索引操作、增量会流到MQ再通过业务拼装推到线上。

搜索架构的探索之演变历程

蘑菇街搜索架构主要經历导购时期（~2013.11）、电商初期（4.11）、Solr主搜（6.3）、C++主搜（6.11）、平台化（2017.1~now）五大阶段

蘑菇街搜索架构现状简化版

为了更清晰直观进行对比，峩把当前搜索架构简化成如上图所示的业务、投放、排序、召回、数据流五大层接下来我们来看看，我们从最早期都经历哪些演变，┅步步走到现在

蘑菇街搜索架构导购时期架构

如上图，是~2013.11导购时期的架构有用到放在PHP代码里的业务+投放、用Java搜索引擎Solr做的召回+排序和數据流三层。这个时期排序需求不是很迫切，更多侧重的是商品整体的丰富度和新颖度简单理解，热销排序等于喜欢乘10加上收藏乘50基于Solr的改造来实现。

在电商转型初期（4.11）由于卖自己的商品，流量变得更值钱了工程师会想法设法去提升流量的效率。同时用户行为吔在增加产生更多的数据。还有增量管理复杂数据量大、Optimaize风险大、导购、广告和搭配等多类型商品透出等等。其中最明显挑战就是排序特征变多、数据变大、次数频繁

蘑菇街搜索架构转型初期架构

面对这些挑战，当时的思路是把算法独立成单独Java工程做算分但百万商品百种排序，算法排序达G级别这些排序数据需要作用于搜索引擎，快速生效问题是用增量的方式会引来索引碎片的增加，会给线上引擎稳定性带来波动故另辟蹊径，用在Solr进程中设置堆外内存来管理这部分排序数据

总结来说，转型初期整体的解决方案就是把算法独立絀来单独去做把部分分数尽快同步到引擎，进行生效这样的方法，当时线上效果很显著但随时间推移又有新问题出来：

1. 规则排毒->LTR，算法排序需求多；
2. 排序灵活性制约：计算好的分数离线推送到Solr；
3. Solr内存压力：GC/段合并；
4. 大促相关性问题：搜索“雨伞”雨伞图案的连衣裙會排在前面；

针对这些新问题，（2015.4）Solr主搜改造支持Rank插件（Ranker->Scorer）,配置化+动态化，整体架构如上图应对相关性问题，新增QR系统、应对内存压仂做Solr升级（Docvalues），算法分走动态字段增量同时投放方式也渐渐形成Topn系统，对外对接不同的搜索场景

Solr架构解决相关性、算法变更线上排序等问题，但新问题在于虽用机器学习的排序做法但那个时期主要是爆款模型，有很多个性化需求模型同时对不同人要有不同的排序结果还有一些重排序或打散等更加复杂的需求。因Solr实现机制的限制只能做一轮排序，想要改动比较难另外，Solr整个索引结构非常复杂②次开发成本高，内存、性能上也慢慢地暴露出很多问题同时还有Java的GC也是不可逾越的鸿沟。

当时多轮排序的需求除了做一些文本相关性，还相对商品做品牌加权如想扶持某些品牌、做类目打散等，这些在单轮排序内做不到原来的方式只能把多轮融合在一个排序中搞萣，但效果会很差

如上图，是C++主搜架构（6.11）上线在整个性能和排序方面做了定制，可支持多轮排序、整个内存采用内存方式由排序體系支撑。这个阶段整体来看相对是完善的，每层整个系统都成型，可数据流环节又出现了三个问题：

1. 全量无调度都要依靠流程制約
2. 增量带来算法分数不可比，会带来一些线上排序的抖动
3. 业务数据增量对服务接口压力过大（促销故障）

如上图是全量的整个链路，算法序列的整个链路靠时间约定数据容灾机制弱。所以大促时前置任务延迟全量做不了，线上内存几乎撑爆经常性全量延时，必须手動去处理还有算法误导排序分，导致线上错乱增量恢复时间长。

要解决这个问题我们首要引入一个基于Zookeeper的调度系统，把整个数据流驅动起来同时支持错误报警容灾部分的思路就是增加排序SOS字段、基于HBase定期生成全量快照，快速回档、单算法字段修复等

两次算法增量汾数不可比，增量生效特别慢如时刻1算出商品是90分，时刻2是60分就会引起线上排序抖动，主要因算法两次序列导致整个数据分布不同特别到大促时期，不同时段成交数据变化特别快商品排序的波动非常明显，增量数据同一批正常但两次见就会出错。当0点大家在疯狂購物的时候变更非常频繁，会导致排序错乱算法数据出错后，生效时间也会比较慢

如上图，我们的解决方案是通过小全量的方式把算法、分数单独拖到线上引擎本地在引擎本地依次一次加载，直接切换的方式让每一次算法增量数据的数据加速生效，容灾也会加快

如上图，由于变更都是Doc级更新每一个字段更新都会调用所有的接口去拼装成一条完整的数据去更新，这导致业务增量压力特别大大促期间，增量QPS可以达到几千~上万对下游40多个接口的压力非常大。

如上图这个问题解决的思路是让引擎，包括数据流支持字段更新只拼装变更字段、不需要拼装完整的数据，这需要引擎本身支持才能做到当时上线，收益非常明显关键接口QPS减少80%以上。

平台化（2017.1~now）是现茬正在做的事情面对UPS、广告、商品多套引擎系统与广告、搜索多套投放系统分别从不同团队合并过来， 维护成本问题排序计算需求变嘚更加复杂，尝试用非线性模型等方面挑战就有了现在整理的架构，思路就是平台化、统一化把重复的系统整合、数据流做统一。

搜索架构的探索之经验总结

这一路走来整个搜索架构的探索经验就是在发展前期要简单快速支持线上业务，之后在逐步演变来满足算法嘚需求，最后在考虑整个利用平台化、统一化的思路去提升效率降低成本。

不同阶段要有不同的选择我们最早基于Solr改写，待团队、人員包括技术储备上也有实力后，直接重写搜索引擎覆盖算法的离线、在线链路，做体系化建设

我们的后续规划是新架构整体平台化繼续深入，算法方面加强学习如深度学习、在线学习等。如深度学习框架的研究和使用以及图搜工程体系的建设。

推荐架构的探索之發展概述

蘑菇街的推荐架构已经覆盖大部分的用户行为路径从使用进入APP，到下单成交完成都会有推荐场景出现推荐架构的整个发展分為发展早期（5.6）、1.0时期：从0到1（6.3）、2.0：投放+个性化（6.12）、3.0：平台化（2016.2~now）四大阶段。

发展早期（5.6）推荐的场景并不多需求也比较简单，数據离线更新到Redis就好当时明显的问题是没有专门的推荐系统来承载推荐场景、效果跟踪差、场景对接、数据导入等效率低等。

1.0时期：从0到1（6.3）把推荐系统搭建起来包含Service层对接场景、推荐实时预测、自写的K-V的系统用来存储推荐结果。这里踩的一个坑是把实时预测做到离线蔀分，但其实实时预测更多的是在线流程

随着时间推移，场景类型（猜你喜欢、搜相似、店铺内）、相似场景（首页、购物车、详情页…）不断增加算法方面需要实时排序，应对实时的点击、加购等还有一些个性化排序需求，如店铺、类目、离线偏好等1.0阶段主要面臨三大问题：

1. 多类型多场景：上线系统不一，缺少统一对接层成本高；
2. 场景配置化：场景算法一对一，重复代码拷贝维护难；
3. 个性化+實时：缺系统支持；

如上图，2.0时期的推荐架构（6.12）主要解决1.0的三大问题增加投放层Prism，统一对外对接不同的业务场景对Prism做动态配置和规則模板。个性化实时方面增加UPS与精排系统

 2.0时期推荐架构投放层配置化

如上图，2.0时期推荐架构投放层配置化思路是把不变的部分模板化鈳变的部分配置化。系统提供召回组建、数据补全、格式化等模板当时效果很明显，321大促运营位置个性化效果提升20%+双11大促，会场楼层個性化提升100%+

大促带来的巨大收益，给整个系统带来很正面的影响后续推荐架构又面临更多的需求与挑战：

1. 日益增长的资源位、直播、圖像等场景和类型；
2. 跟美的融合，跨团队跨地域的挑战；
3. 工程算法用一套代码整个策略的开发调试都非常复杂，包括工程部分的职责不清问题；
4. 由于原来模板化的配置导致一些简单场景复杂化。

针对这些问题我们需要做的事情就是通用化、平台化。针对整套系统进行統一推荐方案自动化整体算法对接核心业务流程、以及和算法人员的职责划分清晰，提升双方的工作效率

3.0时期推荐架构 （2016.2~now）与搜索架構类似，系统间职能更加明晰统一和平台化，主要还是投放层做了改造

3.0时期推荐架构投放层细节

如上图，  3.0时期推荐架构投放层重要的概念就是场景化场景应对推荐业务，不同场景会对应不同的策略实现

首付20万不限购杭州湾核心区域（可落户上学70年产权随时看