电商架构及搜索引擎yu秒杀

1>  概念
电商搜索引擎的架构、数据更新、故障恢复等多个方面的内容.
因为电商搜索引擎主要是解决用户要“买什么”，而通用搜索引擎主要是解决用户“搜什么”。比如同样搜索一个词“百年孤独”，电商的搜索肯定是给你推荐这本书的商家，而百度主要是告诉你：《百年孤独》是一本书。
  众所周知，标准的搜索引擎主要分成三个大的部分，第一步是爬虫系统，第二步是数据分析，第三步才是检索结果。首先，电商的搜索引擎并没有爬虫系统，因为所有的数据都是结构化的，一般都是微软的数据库或者Oracle的数据库，所以不用像百度一样用“爬虫”去不断去别的网站找内容，当然，电商其实也有自己的“爬虫”系统，一般都是抓取友商的价格，再对自己进行调整。
  第二点，就是电商搜索引擎的过滤功能其实比搜索功能要常用。甚至大于搜索本身。什么是过滤功能？一般我们网站买东西的时候，搜了一个关健词，比如尿不湿，然后所有相关品牌或者其他分类的选择就会呈现在我们面前。对百度而言，搜什么词就是什么词，如果是新闻的话，可能在时间上会有一个过滤的选项。

  第三点，电商搜索引擎支持各种维度的排序，包括支持好评、销量、评论、价格等属性的排序。而且对数据的实时性的要求非常高。对一般的搜索引擎，只有非常重要的网站，比如一些重量级的门户网站，百度的收录是非常快的，但是对那些流量很小的网站，可能一个月才会爬一次。电商搜索对数据的实时性要求主要体现在价格和库存两个方面。

一个五年架构师（电商平台的架构设计）- http://blog.csdn.net/Gupaoxueyuan/article/details/79026635

2>  实现
    第一种是“Lucene+自己封装”，只用来做检索，然后封装，后面所有的ES，这两个是完整的解决方案，而且包括索引所有的东西，只需要部署好业务逻辑，然后查找结果就可以了。
    第二种就是Solr，这是一个高性能，采用Java5开发，基于Lucene的全文搜索服务器。同时对其进行了扩展，提供了比Lucene更为丰富的查询语言，同时实现了可配置、可扩展并对查询性能进行了优化，并且提供了一个完善的功能管理界面，是一款非常优秀的全文搜索引擎。
    第三种是ElasticSearch，这是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。Elasticsearch是用Java开发的，并作为Apache许可条款下的开放源码发布，目前使用的也非常多。
    这里提一下，当当的搜索引擎是自己实现的，。现在，新兴的互联网公司大部分都是使用第一种或者第二种，数据量比较大的一般采用第三种。

  最后就是冷启动的问题，这个问题是很多电商网站都很头疼的问题。尤其是随着电商网站的商品数量达到一定量级的时候，比如已经上亿了，像淘宝、天猫的话应该更多。如果重建了一次索引需要启动，或者新上线了一个业务模块，需要重启系统，是很麻烦的。
   当然，当集群大了以后有很多方法，比如分开启动之类的，至于技术嘛，一般索引的加载都是使用Lunix标准的MMAP（MMAP将一个文件或者其它对象映射进内存。文件被映射到多个页上，如果文件的大小不是所有页的大小之和，最后一个页不被使用的空间将会清零。MMAP在用户空间映射调用系统中作用很大），这样启动速度会很快，但是系统会有预热时间，前面一些时间的查询会比较慢
    如果数据量不是特别大的话，而且现在内存也那么便宜，完全可以将数据一次性读入内存，因为mmap的操作毕竟性能没有直接内存来得快。
   第三种的话，就是尽量减少做全量数据的频率，避免整个系统的重启，这需要定期做一下索引的优化，把没用的索引干掉。
   如果是新上了一个业务模块需要重启集群，这样的事情最好不要发生，这就是架构有问题了，将业务模块变成外部的模块或者插件进行上线才是正确的，不然每上线一个模块需要重启集群，这谁都受不了。

》
    虽然整理来看，设计的思路是非常合理的，但是还是会出现问题。一般而言，一个成熟的电商搜索系统，它的问题都很集中，要这几种情况：首先就是Bug，当然这是所有系统都会遇到的问题；第二个就是并发，但是搜索系统是没办法进行分库分表，所以能做的就是索引切分；最后一点就是监控，包括问题追踪、日志系统和监控系统，那么为了解决这些问题，我们应该怎么做？
    首先，针对Bug问题，只能靠自动化运维去解决（这里也推荐使用OneAPM工具）；第二个就是高并发的问题，目前主要是靠缓存和横向扩展。而缓存和横向扩展怎么应用到系统中去，这个很关键。很多人也说可以换一种语言，比如讲Python换成C++，但实际情况下，换语言并不能解决并发的问题，好的数据结构的设计比换一种语言更能提高性能，所以一般解决高并发问题的也就是缓存和横向扩展。
    第三个就是使用用FLUME日志系统（Flume是Cloudera提供的一个高可用的，高可靠的，分布式的海量日志采集、聚合和传输的系统，Flume支持在日志系统中定制各类数据发送方，用于收集数据；同时，Flume提供对数据进行简单处理，并写到各种数据接受方（可定制）的能力）。其实，Flume会把集群上每一个节点的日志全都收集起来，这样做起来有两个好处，第一是现场出问题，可以先回滚出Bug，然后进行查询。第二个就是对日志进行搜集，然后做用户行为分析，查看用户点击了多少次，从何处导入的流量等等，从而便于更好的进行排序。

转载地址：http://21cto.com/post/ec-search-engine-framework-design

商品详情页架构（流量暴击）- http://geek.csdn.net/news/detail/243354
  商品详情页是全量静态化，还是需要动态渲染
  要考虑和要解决的问题有：能迅速响应瞬变和各种变态的需求。支持各种垂直化页面改版。页面模块化。AB 测试。高性能、水平扩容。多机房多活、异地多活。
  前端展示分为2 部分：商品详情页和商品介绍，使用Nginx+Lua 技术获取数据并渲染模板输出。
  详情页架构设计的一些原则如下：数据闭环。数据维度化。拆分系统。Worker 无状态化+任务化。异步化+并发化。多级缓存化。动态化。弹性化。降级开关。多机房多活。多种压测方案。

> 电商秒杀与抢购：全民参与和营销的目的  
高并发,高负载  redis/memcache  脚本；使用Redis实现秒杀、抢购；隔离、动态分离、分层校验
电商技术解密——秒杀系统- https://www.jianshu.com/p/99b39617a1fe
电商秒杀场景的解决策略与具体实现方案- https://blog.csdn.net/qq_28018283/article/details/72715470
淘宝秒杀系统内幕- https://blog.csdn.net/xuefengmiao/article/details/50877170
用Redis轻松实现秒杀系统- https://blog.csdn.net/shendl/article/details/51092916

在Linux环境下安装Redis步骤可参照：http://blog.csdn.net/fengzheku/article/details/50053961
在Window下安装Redis可参照：http://blog.csdn.net/csdn_terence/article/details/77082988

  电商秒杀和抢购，是两个比较典型的互联网高并发场景。秒杀系统本质是还是一个数据读的热点问题。
  一个秒杀或者抢购页面，通常分为2个部分，一个是静态的HTML等内容，另一个就是参与秒杀的Web后台请求接口。通常静态HTML等内容，是通过CDN的部署，一般压力不大，核心瓶颈实际上在后台请求接口上。
  大一点的电商网站往往会将秒杀系统单独开发一套独立的订单流程。独立的流程一是可以跟普通商品交易流程分开，即使受到攻击最坏情况下也不会影响普通商品的购买，另外做成独立的流程比较方便做一些特殊的逻辑来防止被刷的情况。

秒杀系统设计的第一个原则就是将这种热点数据隔离出来，不要让1%的请求影响到另外的99%，隔离出来后也更方便对这1%的请求做针对性优化。针对秒杀我们做了多个层次的隔离：
  业务隔离。把秒杀做成一种营销活动，卖家要参加秒杀这种营销活动需要单独报名，从技术上来说，卖家报名后对我们来说就是已知热点，当真正开始时我们可以提前做好预热。
  系统隔离。系统隔离更多是运行时的隔离，可以通过分组部署的方式和另外99%分开。秒杀还申请了单独的域名，目的也是让请求落到不同的集群中。
  数据隔离。秒杀所调用的数据大部分都是热数据，比如会启用单独cache集群或MySQL数据库来放热点数据，目前也是不想0.01%的数据影响另外99.99%。
 
  对大流量系统的数据做分层校验也是最重要的设计原则，所谓分层校验就是对大量的请求做成“漏斗”式设计。对数据做分层的校验，下面是一些原则：
先做数据的动静分离；
将90%的数据缓存在客户端浏览器；
将动态请求的读数据Cache在Web端；
对读数据不做强一致性校验；
对写数据进行基于时间的合理分片；
对写请求做限流保护；
对写数据进行强一致性校验；

分离热点商品到单独的数据库还是没有解决并发锁的问题，要解决并发锁有两层办法。
  应用层做排队。按照商品维度设置队列顺序执行，这样能减少同一台机器对数据库同一行记录操作的并发度，同时也能控制单个商品占用数据库连接的数量，防止热点商品占用太多数据库连接。
  数据库层做排队。应用层只能做到单机排队，但应用机器数本身很多，这种排队方式控制并发仍然有限，所以如果能在数据库层做全局排队是最理想的，淘宝的数据库团队开发了针对这种MySQL的InnoDB层上的patch，可以做到数据库层上对单行记录做到并发排队。

 秒杀系统应对策略：1，秒杀系统独立部署；2，页面静态化；3，租借秒杀活动网络带宽；4，动态的下单URL
 秒杀地址接口的优化策略：请求地址，先访问redis，如果redis缓存中没有所需资源或者访问访问超时，则直接进入mysql获取系统资源，将获取的内容更新在redis当中（策略：超时穿透，主动更新）。

秒杀业务分析：
1.正常电子商务流程（1）查询商品；（2）创建订单；（3）扣减库存；（4）更新订单；（5）付款；（6）卖家发货
2.秒杀业务的特性（1）低廉价格；（2）大幅推广；（3）瞬时售空；（4）一般是定时上架；（5）时间短、瞬时并发量高；