项目经验（一）

怎么保证促销商品不会超卖

这个问题是我们当时开发时遇到的一个难点，超卖的原因主要是下的订单的数目和我们
要促销的商品的数目不一致导致的，每次总是订单的数比我们的促销商品的数目要多，当时
我们的小组讨论了好久，给出了好几个方案来实现：
第一种方案是：①在每次下订单前我们判断促销商品的数量够不够，不够不允许下订单，
更改库存量时加上一个条件，只更改商品库存大于 0 的商品的库存，当时我们使用 ab 进行
压力测试，当并发超过 500，访问量超过 2000 时，还是会出现超卖现象。所以被我们否定
了。
第二种方案是：②使用 mysql 的事务加排他锁来解决，首先我们选择数据库的存储引擎
为 innoDB，使用的是排他锁实现的，刚开始的时候我们测试了下共享锁，发现还是会出现
超卖的现象。有个问题是，当我们进行高并发测试时，对数据库的性能影响很大，导致数据
库的压力很大，最终也被我们否定了。
第三种方案是：③使用文件锁实现。当用户抢到一件促销商品后先触发文件锁，防止其
他用户进入，该用户抢到促销品后再解开文件锁，放其他用户进行操作。这样可以解决超卖
的问题，但是会导致文件得 I/O 开销很大。
最后我们使用了 redis 的队列来实现。将要促销的商品数量以队列的方式存入 redis 中，
每当用户抢到一件促销商品则从队列中删除一个数据，确保商品不会超卖。这个操作起来很
方便，而且效率极高，最终我们采取这种方式来实现

对网站大访问量的优化方案

提高访问速度。从硬件，最好从网站程序等等方面考虑。我给出以下几种方案：
1.尽量使用静态页，不要老使用动态信息调用。非常容易出问题
2.图片内容与网站数据尽量放在同一个服务器或者机房内。大量外链图片是会有问题的
3.一次又一次，一遍又一遍的分析流量走向，然后缩短浏览者浏览距离，举个例子，浏
览者如果现在在你网站看一个新闻需要点 5 次鼠标，你就要缩短这个点击数。
4.一次又一次，一遍又一遍的分析，修改你的网站数据库结构，使其更加简洁。
5.提高网站的安防能力
6.买个好服务器，托管在一个好的机房

网站高并发 大流量访问的处理及解决方法

第一:确认服务器硬件是否足够支持当前的流量。
普通的 P4 服务器一般最多能支持每天 10 万独立 IP，如果访问量比这个还要大，那么必
须首先配置一台更高性能的专用服务器才能解决问题，否则怎么优化都不可能彻底解决
性能问题。
第二：优化数据库访问
前台实现完全的静态化当然最好，可以完全不用访问数据库，不过对于频繁更新的网
站，静态化往往不能满足某些功能。
缓存就是另一个解决方案，就是将动态数据存储到缓存文件中，动态网页直接调用这
些文件，而不必再访问数据库，技术如果确实无法避免对数据库的访问，那么可以尝试
优化数据库的查询 SQL.避免使用 Select * from 这样的语句，每次查询只返回自己需要
的结果，避免短时间内的大量 SQL 查询。最好在相同字段进行比较操作,在建立好的索
引字段上尽量减少函数操作，如果要做到极致的话需要代码的优化；
第三，禁止外部的盗链。
外部网站的或者文件盗链往往会带来大量的负载压力，因此应该严格限制外部对于
自身的图片或者文件盗链，好在目前可以简单地通过 refer 来控制盗链，自己就可以通
过配置来禁止盗链。当然，伪造 refer 也可以通过来实现盗链，不过目前蓄意伪造 refer
盗链的还不多，可以先不去考虑，或者使用非技术手段来解决，比如在图片上增加水印。
第四，控制大文件的下载。
大文件的下载会占用很大的流量，并且对于非 SCSI 硬盘来说，大量文件下载会消耗
CPU，使得网站响应能力下降。因此，尽量不要提供超过 2M 的大文件下载，如果需要提
供，建议将大文件放在另外一台服务器上。
第五，使用不同主机分流主要流量
将文件放在不同的主机上，提供不同的镜像供用户下载。比如如果觉得 RSS 文件占
用流量大，那么使用 FeedBurner 或者 FeedSky 等服务将 RSS 输出放在其他主机上，这
样别人访问的流量压力就大多集中在 FeedBurner 的主机上，RSS 就不占用太多资源了。
第六，使用流量分析统计软件。
在网站上一个流量分析统计软件，可以即时知道哪些地方耗费了大量流量，哪些页面
需要再进行优化，因此，解决流量问题还需要进行精确的统计分析才可以。我推荐使用
的流量分析统计软件是 Analytics（Google 分析）。

主要运用到哪些缓存

一、数据缓存
这里所说的数据缓存是指数据库查询缓存，每次访问页面的时候,都会先检测相应的缓
存数据是否存在，如果不存在，就连接数据库，得到数据，并把查询结果序列化后保存
到文件中，以后同样的查询结果就直接从缓存表或文件中获得。
用的最广的例子看 Discuz 的搜索功能，把结果 ID 缓存到一个表中，下次搜索相同关键
字时先搜索缓存表。
举个常用的方法，多表关联的时候，把附表中的内容生成数组保存到主表的一个字段中，
需要的时候数组分解一下，这样的好处是只读一个表，坏处就是两个数据同步会多不少
步骤，数据库永远是瓶颈，用硬盘换速度，是这个的关键点。
二、页面缓存
每次访问页面的时候，都会先检测相应的缓存页面文件是否存在，如果不存在，就连接
数据库，得到数据，显示页面并同时生成缓存页面文件，这样下次访问的时候页面文件
就发挥作用了。(模板引擎和网上常见的一些缓存类通常有此功能)。
三、时间触发缓存
检查文件是否存在并且时间戳小于设置的过期时间,如果文件修改的时间戳比当前时间
戳减去过期时间戳大，那么就用缓存，否则更新缓存。
四、内容触发缓存
当插入数据或更新数据时，强制更新缓存。
五、静态缓存
这里所说的静态缓存是指静态化，直接生成 HTML 或 XML 等文本文件，有更新的时候重
生成一次，适合于不太变化的页面，这就不说了。
六、内存缓存
Memcached 是高性能的，分布式的内存对象缓存系统，用于在动态应用中减少数据
库负载，提升访问速度。redis 也可以做到。

Cookie 怎么存储购物车信息？

用 cookie 实现购物车，可以减小数据库的压力，不用每一次用户查看购物车都是从数据库
中获取。为了保持 cookie 中的购物车和数据库中的购物车数据相同，
应该是把 cookie 中购物车的数据和数据库中购物车的数据保持同步，用户不登陆时，把购
物车相关数据保存到 cookie 中，登陆后可以把 cookie 数据转移到数据库中。
在存储过程中，要注意 cookie 不能存数组及 cookie 的键的唯一性问题。
①存多条数据到数组中，数组的键为购物车中唯一的标识，如货品 ID 或者 SKU，值为购物
车相关数据的数组。
②把数组通过序列化或者 json_encode 转换为字符串后，存储到 cookie 中
③当有相同的数据再次存 cookie 时，先判断是否有值，然后把 cookie 数据取出来，转换为
数组，相关的数据进行替换后，再存入数组，并且进行字符串处理，再次存到 cookie 中

商城秒杀的实现

抢购、秒杀是如今很常见的一个应用场景，主要需要解决的问题有两个：
1 高并发对数据库产生的压力
2 竞争状态下如何解决库存的正确减少（"超卖"问题）
对于第一个问题，已经很容易想到用缓存来处理抢购，避免直接操作数据库，例如使用
Redis。第二个问题，我们可以使用 redis 队列来完成，把要秒杀的商品放入到队列中，
因为 pop 操作是原子的，即使有很多用户同时到达，也是依次执行，文件锁和事务在高
并发下性能下降很快，当然还要考虑其他方面的东西，比如抢购页面做成静态的，通过
ajax 调用接口，其中也可能会出现一个用户抢多次的情况，这时候需要再加上一个排队
队列和抢购结果队列及库存队列。高并发情况下，将用户进入排队队列，用一个线程循
环处理从排队队列取出一个用户，判断用户是否已在抢购结果队列，如果在，则已抢购，
否则未抢购，库存减 1，写数据库，将用户入结果队列。

购物车的原理

购物车相当于现实中超市的购物车，不同的是一个是实体车，一个是虚拟车而已。用
户可以在购物网站的不同页面之间跳转，以选购自己喜爱的商品，点击购买时，该商品
就自动保存到你的购物车中，重复选购后，最后将选中的所有商品放在购物车中统一到
付款台结账，这也是尽量让客户体验到现实生活中购物的感觉。服务器通过追踪每个用
户的行动，以保证在结账时每件商品都物有其主。
主要涉及以下几点:
1、把商品添加到购物车，即订购
2、 删除购物车中已定购的商品
3、 修改购物车中某一本图书的订购数量
4、 清空购物车
5、 显示购物车中商品清单及数量、价格
实现购物车的关键在于服务器识别每一个用户并维持与他们的联系。但是 HTTP 协
议是一种“无状态(Stateless)”的协议，因而服务器不能记住是谁在购买商品，当把
商品加入购物车时，服务器也不知道购物车里原先有些什么，使得用户在不同页面间跳
转时购物车无法“随身携带”，这都给购物车的实现造成了一定的困难。
目前购物车的实现主要是通过 cookie、session 或结合数据库的方式。下面分析
一下它们的机制及作用。

1. cookie
   cookie 是由服务器产生，存储在客户端的一段信息。它定义了一种 Web 服务器在
   客户端存储和返回信息的机制，cookie 文件它包含域、路径、生存期、和由服务器设置
   的变量值等内容。当用户以后访问同一个 Web 服务器时，浏览器会把 cookie 原样发送
   给服务器。通过让服务器读取原先保存到客户端的信息，网站能够为浏览者提供一系列
   的方便，例如在线交易过程中标识用户身份、安全要求不高的场合避免用户重复输入名
   字和密码、门户网站的主页定制、有针对性地投放广告等等。利用 cookie 的特性，大
   大扩展了 WEB 应用程序的功能，不仅可以建立服务器与客户机的联系，因为 cookie 可
   以由服务器定制，因此还可以将购物信息生成 cookie 值存放在客户端，从而实现购物
   车的功能。用基于 cookie 的方式实现服务器与浏览器之间的会话或购物车，有以下特
   点：
   1、 cookie 存储在客户端，且占用很少的资源，浏览器允许存放 300 个 cookie，每
   个 cookie 的大小为 4KB，足以满足购物车的要求，同时也减轻了服务器的负荷；
   2、 cookie 为浏览器所内置，使用方便。即使用户不小心关闭了浏览器窗口，只要
   在 cookie 定义的有效期内，购物车中的信息也不会丢失；
   3、 cookie 不是可执行文件，所以不会以任何方式执行，因此也不会带来病毒或攻击
   用户的系统；
   4、 基于 cookie 的购物车要求用户浏览器必须支持并设置为启用 cookie，否则购物
   车则失效；
   5、 存在着关于 cookie 侵犯访问者隐私权的争论，因此有些用户会禁止本机的 cookie
   功能。
2. session
   session 是实现购物车的另一种方法。session 提供了可以保存和跟踪用户的状态
   信息的功能，使当前用户在 session 中定义的变量和对象能在页面之间共享，但是不能
   为应用中其他用户所访问，它与 cookie 最重大的区别是，session 将用户在会话期间的
   私有信息存储在服务器端，提高了安全性。在服务器生成 session 后，客户端会生成一
   个 sessionid 识别号保存在客户端，以保持和服务器的同步。这个 sessionid 是只读的，
   如果客户端禁止 cookie 功能，session 会通过在 URL 中附加参数，或隐含在表单中提交
   等其他方式在页面间传送。因此利用 session 实施对用户的管理则更为安全、有效。
   同样，利用 session 也能实现购物车，这种方式的特点是：
   1、 session 用新的机制保持与客户端的同步，不依赖于客户端设置；
   2、 与 cookie 相比，session 是存储在服务器端的信息，因此显得更为安全，因此可将
   身份标示，购物等信息存储在 session 中；
   3、session 会占用服务器资源，加大服务器端的负载，尤其当并发用户很多时，会生成
   大量的 session，影响服务器的性能；
   4、因为 session 存储的信息更敏感，而且是以文件形式保存在服务器中，因此仍然存
   在着安全隐患。
3. 结合数据库的方式
   这也是目前较普遍的模式，在这种方式中，数据库承担着存储购物信息的作用，
   session 或 cookie 则用来跟踪用户。这种方式具有以下特点：
   1、 数据库与 cookie 分别负责记录数据和维持会话，能发挥各自的优势，使安全性和
   服务器性能都得到了提高；
   2、每一个购物的行为，都要直接建立与数据库的连接，直至对表的操作完成后，连接
   才释放。当并发用户很多时，会影响数据库的性能，因此，这对数据库的性能提出了更
   高的要求；
   3、使 cookie 维持会话有赖客户端的支持。
   各种方式的选择：
   虽然 cookie 可用来实现购物车，但必须获得浏览器的支持，再加上它是存储在客
   户端的信息，极易被获取，所以这也限制了它存储更多，更重要的信息。所以一般 cookie
   只用来维持与服务器的会话，例如国内最大的当当网络书店就是用 cookie 保持与客户
   的联系，但是这种方式最大的缺点是如果客户端不支持 cookie 就会使购物车失效。
   Session 能很好地与交易双方保持会话，可以忽视客户端的设置。在购物车技术
   中得到了广泛的应用。但 session 的文件属性使其仍然留有安全隐患。
   结合数据库的方式虽然在一定程度上解决了上述的问题，但从上面的例子可以看出：在
   这种购物流程中涉及到对数据库表的频繁操作，尤其是用户每选购一次商品，都要与数
   据库进行连接，当用户很多的时候就加大了服务器与数据库的负荷。

redis 消息队列先进先出需要注意什么

通常使用一个 list 来实现队列操作，这样有一个小限制，所以的任务统一都是先进
先出，如果想优先处理某个任务就不太好处理了，这就需要让队列有优先级的概念，我
们就可以优先处理高级别的任务，实现方式有以下几种方式：
1）单一列表实现：队列正常的操作是 左进右出（lpush,rpop）为了先处理高优先
级任务，在遇到高级别任务时，可以直接插队，直接放入队列头部（rpush），这样，
从队列头部（右侧）获取任务时，取到的就是高优先级的任务（rpop）
2）使用两个队列，一个普通队列，一个高级队列，针对任务的级别放入不同的队列，
获取任务时也很简单，redis 的 BRPOP 命令可以按顺序从多个队列中取值，BRPOP 会按
照给出的 key 顺序查看，并在找到的第一个非空 list 的尾部弹出一个元素，redis>
BRPOP list1 list2 0
list1 做为高优先级任务队列
list2 做为普通任务队列
这样就实现了先处理高优先级任务，当没有高优先级任务时，就去获取普通任务
方式 1 最简单，但实际应用比较局限，方式 3 可以实现复杂优先级，但实现比较复杂，
不利于维护
方式 2 是推荐用法，实际应用最为合适

你负责的模块有哪些难题

在我负责的 B2B 电商项目中，当时我负责的是订单模块，由于客户一次选择了多家
商户的商品，最终生成了一个订单，这样我们平台在给商户结算时出现了不知道这比费
用应该给哪个商户，这时候我们小组经过讨论，需要涉及到订单拆分，也就是说用户点
击支付后,如果有多件商品,并且不是同一家店铺那么 就要用到订单的拆分,比如如果
有两件商品,并且不是同一店铺 就在原来的订单号下 在生成两个子订单号 并修改订
单表中两件商品的订单号。最终实现了商品的分配管理，解决了我们的难题。
我觉得在开发过程中，遇到的难题无非是两个，一个是技术层次的，我认为，只要
你有恒心，有热心，没有觉得不了的难题。另一个就是沟通问题，在任何地方任何时候
沟通都是最重要的，尤其是我们做开发的，不沟通好，会影响整个项目的进度，我本人
是个非常还沟通的人，所以这点上也没多大问题。

用户下单是怎么处理的

判断用户有没有登录，在没有登录的情况下，不允许下单。登陆后，可进行下单
并生成唯一的订单号，此时订单的状态为未支付。

电商的登录是怎么登录的

分为普通登录和第三方登录 这边主要说一下第三方登录吧，第三方登陆主要使用的
是 author 协议，我就以 QQ 的第三方登陆为例来进行说明：当用户在我们的站点请求 QQ
的第三方登陆时，我们站点会引导用户跳转到 QQ 的登陆授权界面， 当用户输入 QQ 和
密码成功登录以后会自动跳回到我们站点设置好的回调页面，并附带一个 code 参数，
接着你使用 code 再次去请求 QQ 的授权页面，就可以从中获取到一个 access token（访
问令牌），通过这个 access_token，我们可以调用 QQ 提供给我们的接口，比如获取
open_id，可以获取用户的基本信息。获取到之后，我们需要拿用户的授权信息和 open_id
和我们平台的普通用户进行绑定。这样不管是普通用户登陆还是第三方登陆用户，都可
以实现登陆。

有负责开发 app 吗

我以前有过使用 hybrid APP 开发过 APP，做过一个简单的广场舞 APP，但我主要
参与到 APP 的接口编写这块中。

开发 app 过程中遇到了什么难题

hybrid APP 开发过程中，前端知识是我的硬伤，以前，前端我一直都没有花太多
精力在上面，所以在使用 hybrid APP 开发过程中，页面样式总是调得很难看，后面我
花了一周时间自己自学恶补了以下前端的东西，感觉收获很大。还有我记得以前在公司
写接口时，我们的安卓工程师认为他们 APP 的分页效果，得我们接口这边事先分好页，
然后他们再调用接口，其实分页的页码需要他那边提供给我们，但是他就认定了是我们
这边的问题，后面经过多次沟通和测试，我们共同完成了这项任务。

你是如何测试网站的性能的

常用的网站性能测试有：压力测试，负载测试，容量测试，并发性能测试，兼容性
测试（不同的操作系统和不同的浏览器）。在项目正式上线前，我们技术部会使用压力
测试工具来测试网站的性能（我们主要是进行压力测试的）。我主要用过两款软件：一
个 apache 自带的 ab 压力测试工具，这个测试的最大并发量相对较小，一般 1000 左右
就会出现请求拒绝。另一个软件是 webbench,这个软件首先得安装，最大并发可以到 3W。
当然还有一些其他的专业的测试工具，如国外的 Page Speed Online、Pingdom Tools
等等，我们公司有专门的测试部，我们会配合他们完成测试工作。

ab 命令参数是什么

ab.exe -n 5000 -c 50 http://www.test.com/index.php
-n 是总的执行次数，-c 并发的次数， http://www.test.com/index.php 要执行的文件

用的什么技术实现短信发送，在哪调用

我主要用的第三方短信接口，在申请接口时进行相应信息的配置，然后在我们站点需
要用到短信验证的地方进行调用，我们通常在用户注册时使用到。

上一家公司用的什么框架写的项目，还接触过什么框架?
我的上一家公司主要使用的是 XXX 框架，我对该框架非常熟悉，我们公司在该框架
上做了一些相应的扩展，引入了一些自己编写的类库文件和插件库。我以前还使用过
yii2,ci、laravel 框架，以前还自己封装过 MVC 框架。一个新的框架掌握起来很容易，
你只要抓住其中的几个点，比如路由规则、MVC、数据库相关的操作，其他的都可以查
手册，孰能生巧，通过一个小项目就可以把框架用得很熟，当然框架底层的东西，我们
还是得用一些好的 IDE 工具去追它的底层源码。

在工作中遇到什么困难?

总体来说：在工作我主要遇到这几个问题比较难处理：
①我之前工作的时候发现经常会出现一些临时需求打乱了我的计划，搞得有时候这
个任务还没完成，又得去做其他的任务，最后一天下来，大大小小的东西是很多，但是
没有完成得非常好的，后面我总结了一下，我会把这些都添加优先级，遇到临时需求，
按照优先级重新将已有任务和临时任务进行排版，保证在规定时间内有效率的完成优先
级高的任务。
②在做项目需求时候，遇到理解能力欠佳的人，沟通时容易被气到，影响自己的情绪，
最后反倒还不能到达需要的效果。后面，每次到这种时候，我一般会借助一些纸质的、
更加形象的东西，让双方都认同的、都能明白的一种方式来进行沟通，后面减少了很多
不必须的麻烦。大家都知道，对于程序员来说，改需求是一件很痛苦的事情，所以前期
的沟通工作很重要。
③还有一件事时，我以前的领导不太懂技术，所以每次出一个新的需求出来，总是要
求我们在很短的时间内完成，完不成我们就会被怀疑能力有问题。当然，每个领导都希
望自己的员工能够尽快的完成任务，降低成本，提高效率。这时候我会把我们的需求细
化，把其中的重点、难点都列出来，做好时间规划，耐心的跟领导沟通，项目每个点的
重要性和时间的花费比例，确保在这个规划的时间点内保质保量的完成任务。慢慢的也
得到了领导的认可，其实领导也不是一味的不通情理，只要把东西计划好了，以最小的
代价换取最高的价值，每个人都是很容易理解得。

直播是怎么实现的?

①直播视频从技术架构角度主要分为三个部分：
直播视频采集 SDK=>直播 CDN（也即直播流分发加速）=》直播视频播放器 SDK
②音视频处理的一般流程：
数据采集→数据编码→数据传输(流媒体服务器) →解码数据→播放显示
1、数据采集：摄像机及拾音器收集视频及音频数据，此时得到的为原始数据，要用到
摄像机和拾音器。
2、数据编码:使用相关硬件或软件对音视频原始数据进行编码处理（数字化）及加工（如
音视频混合、打包封装等），得到可用的音视频数据,编码的方式：CBR、VBR，编码格
式分为音频和视频，音频一般有 MP3、OGG、AAC，视频一般有 TS、MKV、AVI、MP4 等。
3、数据传输：将编码完成后的音视频数据进行传输，早期的音视频通过同轴电缆之类
的线缆进行传输，IP 网络发展后，使用 IP 网络优传输
涉及技术或协议：
传输协议：RTP 与 RTCP、RTSP、RTMP、HTTP、HLS（HTTP Live Streaming）等
控制信令：SIP 和 SDP、SNMP 等
4、解码数据：
使用相关硬件或软件对接收到的编码后的音视频数据进行解码，得到可以直接显示的图
像/声音
涉及技术或协议：
一般对应的编码器都会带有相应的解码器，也有一些第三方解码插件等
5、播放显示：
在显示器（电视、监视屏等）或扬声器（耳机、喇叭等）里，显示相应的图像画面或声
音
涉及技术或协议：
显示器、扬声器、3D 眼镜等

写过接口吗，怎么定义接口的

答案：写过。接口分为两种：一种是数据型接口，一种是应用型接口。
数据型接口：是比抽象类更抽象的某种“结构”——它其实不是类，但是跟类一样
的某种语法结构，是一种结构规范，规范我们类要以什么格式进行定义，一般用于团队
比较大，分支比较多的情况下使用。
应用型接口： API（application interface） 数据对外访问的一个入口
我主要是参与的 APP 开发中接口的编写，客户端需要什么样的数据，我们就给他们
提供相应的数据，数据以 json/xml 的格式返回，并且配以相应的接口文档。

静态化如何实现的

答：这里要说的静态化指的是页面静态化，也即生成实实在在的静态文件，也即不需要
查询数据库就可以直接从文件中获取数据，指的是真静态。它的实现方式主要有两种：
一种是我们在添加信息入库的时候就生成的静态文件，也称为模板替换技术，这种
主要用在后台，用于一些基本上很少变化的信息上，在添加信息的时候使用添加的信息
来替换制定好的模板中的内容，达到生成静态文件的目的，这样在前台访问该信息时，
可以直接从生成好的静态文件中获取信息，如一些 CMS 系统。
另外一种是用户在访问我们的页面时先判断是否有对应的缓存文件存在，如果存在
就读缓存，不存在就读数据库，同时生成缓存文件。这种实现的主要原理是基于 PHP 中
的 ob 缓冲技术来实现的，当没有静态文件时，从数据库中读取，读取的数据使用 OB 缓
存，使用相关的函数从 OB 缓冲中读取数据，写入到文件中，形成静态文件。当然这个
过程中要考虑静态文件的缓存周期问题，我们可以根据文件的最后修改时间和当前时间
及设定的缓存时间来定时更新缓存文件。

伪静态如何实现的

答：伪静态不是真正意义上的静态化，之所以使用伪静态，主要是为了 SEO 推广，搜索
引擎对动态的文件获取难度大，不利于网站的推广。伪静态的实现原理主要是基于
apache/nginx 等 web 服务器的 rewrite 机制。利用 Apache/nginx 里面相关的服务器变
量和指令来完成重写。主要有两种方式，一种是直接在配置虚拟机的位置配置伪静态，
这个每次修改完成后需要重启 web 服务器。另一种采用分布式的，可以在网站的根目录
上创建.htaccess 的文件，在里面配置相应的重写规则来实现伪静态，这种每次重写时
不需要重启 web 服务器，且结构上比较清晰。具体的配置可以参考 Apache/nginx 的手
册。

sku 减库存

SKU = Stock Keeping Unit (库存量单位)
即库存进出计量的单位，可以是以件，盒，托盘等为单位。SKU 是库存量单位，区分单
品。
在服装、鞋类商品中使用最多最普遍。 例如纺织品中一个 SKU 通常表示：规格、颜色、
款式。
在设计表时，不仅仅只有商品表，商品表中有个总库存，我们还需要涉及一张 SKU 表，
里面有 SKU 库存和单价字段，用户每购买一件商品，实际上购买的都是 SKU 商品，这样
在下订单成功后，应该根据所购买的商品的唯一的 SKU 号来进行相应的 SKU 库存的减少，
当然商品的总库存保存在商品主表中，也需要减少总库存中的库存量。

库存设置？

库存分为商品总库存和 SKU 库存，往往商品总库存的为 SKU 库存的总和。一般在商
城的后台对货品设置最高库存及最低库存后，当前库存数量与最高、最低两者比较，超
出库存或者低于库存的，则被统计成报表形式反映，便于用户掌握货品库存超、短缺状
态及数量。

订单、库存两个表 如何保证数据的一致性？

在一个电子商务系统中，正常的应该是订单生成成功后，相应的库存进行减少。
必须要保证两者的一致性，但有时候因为某些原因，比如程序逻辑问题，并发等问题，
导致下单成功而库存没有减少的情况。这种情况我们是不允许发生的，MySQL 中的事务
刚好可以解决这一问题，首先得选择数据库的存储引擎为 innoDB,事务规定了只有下订
单完成了，并且相应的库存减少了才允许提交事务，否则就事务回滚，确保数据一致性。

O2O 用户下单 c 端下单 如何保证 b a 端 数据一

致 O2O 为线上和线下模式， O2O 模式奉行的是“线上支付+实体店消费”的消费模
式，即消费者在网上下单完成支付后，凭消费凭证到实体店消费。O2O 模式是把商家信
息和支付程序放在线上进行，而把商品和服务兑现放在线下，也就是说 O2O 模式适用于
快递无法送达的有形产品。数据一致性的问题是 O2O 行业中最常见的问题，我们可以类
似于数据库的主从复制的思路来解决这个问题。O2O 有个供应商系统，类似于主服务器，
在 C 端（从服务器）下单时，数据同步更新到供应商系统端，b、a 实时从供应商系统中
拉取数据进行同步，比如利用定时任务，定时拉取数据进行同步。

开源产品的弊端

很多公司为了快速的开发出一款产品，降低成本，往往会采用一些开源的产品来完
成，一款好的开源产品可以起到事半功倍的效果，我们只需要在它的基础上做些二次开
发，就可以达到我们想要的简单的效果。但是，往往这些开源产品也有自己的弊端。
比如我以前用过的 ecshop:产品线不完整，只有单用户产品，后台操作过于烦杂，
无用功能比较多，使用起来有很多 BUG 和不便，系统功能相对薄弱，运营起来很费人力
成本。被商派收购之后，宣传推广也停滞不前。而且是面向过程的，你必须按照它的规
则进行修改，操作起来相对很繁琐。对 PHP5.4 以上的版本支持不好，jQuery 的兼容性
上要好好处理。
PHPCMS：静态处理不好，SEO 有待加强，访问速度也较慢。
Shopex：代码不开源，修改很麻烦，只能通过插件的方式去改进，底层是不知道
的，有漏洞更新也是很慢，当数量达到一定量的时候 shopex 很吃内存服务质量也不好，
基本用户提的意见,很难被有效采取。最头疼的是他的后台操作，易用性很差，前台模
板也不好看。并且系统各方面的压力承受能力都有不足。
系统出了问题也只能等待解决，有受制于人的感觉。
总之，使用别人成型的东西，就要遵循别人的规范，责任在于自己。

做秒杀用什么数据库，怎么实现的。

因为秒杀的一瞬间，并发非常大，如果同时请求数据库，会导致数据库的压力非常
大，导致数据库的性能急剧下降，更严重的可能会导致数据库服务器宕机。这时候一般
采用内存高速缓存数据库 redis 来实现的,redis 是非关系型数据库，redis 是单线程的，
通过 redis 的队列可以完成秒杀过程

支付宝流程怎么实现的

首先要有一个支付宝账号，接下来向支付宝申请在线支付业务，签署协议。协议生
效后有支付宝一方会给网站方一个合作伙伴 ID,和安全校验码，有了这两样东西就可以
按照支付宝接口文档开发支付宝接口了，中间主要涉及到一个安全问题。整个流程是这
样的：我们的网站通过 post 传递相应的参数（如订单总金额，订单号）到支付页面，
支付页面把一系列的参数经过处理，以 post 的方式提交给支付宝服务器，支付宝服务
器进行验证，并对接收的数据进行处理，把处理后的结果返回给我们网站设置的异步和
同步回调地址，通过相应的返回参数，来处理相应的业务逻辑，比如返回的参数代表支
付成功，更改订单状态

怎么实现第三方登录？

第三方登陆主要是基于 author 协议来实现，下面简单说下实现流程:
1、首先我们需要以开发者的身份向第三方登陆平台申请接入应用，申请成功后，我们
会获得一个 appID 和一个 secrectID.
2、当我们的网站需接入第三方登陆时，会引导用户跳转到第三方的登陆授权页面，
此时把之前申请的 appID 和 secrectID 带给登陆授权页面。
3、用户登陆成功后即得到授权，第三方会返回一个临时的 code 给我们的网站。
4、我们的网站接受到 code 后，再次向我们的第三方发起请求，并携带接收的 code,
从第三方获取 access_token.
5、第三方处理请求后，会返回一个 access_token 给我们的网站，我们的网站获取
到 access_token 后就可以调用第三方提供的接口了，比如获取用户信息等。最后把该
用户信息存入到我们站点的数据库，并把信息保存到 session 中，实现用户的第三方登
陆。