1.权限管理(RBAC)的实现?
答: 1.首先创建一张用户表:id name auto(保存格式为:控制器-方法) 2.然后在后台中创建一个基类控制器,控制器里封装一个构造方法,当用户登陆成功后,使用 TP 框架中封装好的 session 函数获取保存在服务器中的 session id,然后实例化模型,通过用户 id 获取保存在数据表中的 auth 数据,使用 explode 函数分割获取到的数据,并使用一个数组保存起来,然后使用 TP 框架中封装好的常量获取当前控制器和方法,然后把他们组装成字符串,使用 in_array 函数进行判断该数组中是否含有当前获取到的控制器和方法,如果没有,就提示该用户没有权限,如果有就进行下一步操作
2.怎么保证促销商品不会超卖
答:这个问题是我们当时开发时遇到的一个难点，超卖的原因主要是下的订单的数目和我们要促销的商品的数目不一致导致的，每次总是订单的数比我们的促销商品的数目要多，当时我们的小组讨论了好久，给出了好几个方案来实现： 第一种方案是：①在每次下订单前我们判断促销商品的数量够不够，不够不允许下订单，更改库存量时加上一个条件，只更改商品库存大于 0 的商品的库存，当时我们使用 ab 进行压力测试，当并发超过 500，访问量超过 2000 时，还是会出现超卖现象。所以被我们否定了。 第二种方案是：②使用 mysql 的事务加排他锁来解决，首先我们选择数据库的存储引擎为 innoDB，使用的是排他锁实现的，刚开始的时候我们测试了下共享锁，发现还是会出现超卖的现象。有个问题是，当我们进行高并发测试时，对数据库的性能影响很大，导致数据库的压力很大，最终也被我们否定了。 第三种方案是：③使用文件锁实现。当用户抢到一件促销商品后先触发文件锁，防止其他用户进入，该用户抢到促销品后再解开文件锁，放其他用户进行操作。这样可以解决超卖的问题，但是会导致文件得 I/O 开销很大。 最后我们使用了 redis 的队列来实现。将要促销的商品数量以队列的方式存入 redis 中，每当用户抢到一件促销商品则从队列中删除一个数据，确保商品不会超卖。这个操作起来很方便，而且效率极高，最终我们采取这种方式来实现
3.商城秒杀的实现
答:抢购、秒杀是如今很常见的一个应用场景，主要需要解决的问题有两个： 1 高并发对数据库产生的压力 2 竞争状态下如何解决库存的正确减少（”超卖”问题） 对于第一个问题，已经很容易想到用缓存来处理抢购，避免直接操作数据库，例如使用 Redis。 第二个问题，我们可以使用 redis 队列来完成，把要秒杀的商品放入到队列中，因为 pop 操作是原子的，即使有很多用户同时到达，也是依次执行，文件锁和事务在高并发下性能下降很快，当然还要考虑其他方面的东西，比如抢购页面做成静态的，通过 ajax 调用接口，其中也可能会出现一个用户抢多次的情况，这时候需要再加上一个排队队列和抢购结果队列及库存队列。高并发情况下，将用户进入排队队列，用一个线程循环处理从排队队列取出一个用户，判断用户是否已在抢购结果队列，如果在，则已抢购，否则未抢购，库存减 1，写数据库，将用户入结果队列。
4.MySQL数据库作为系统的存储，一天五万条以上的增量， 预计运维三年,怎么优化？
设计良好的数据库结构，允许部分数据冗余，尽量避免 join 查询，提高效率。
选择合适的表字段数据类型和存储引擎，适当的添加索引。
MySQL分出主从库，做读写分离。
通过一定得规律做分表，以此来减少单表中的数据量，提高查询速度。
添加缓存中间件，减轻数据库访问压力。
对那些不经常改动的页面，可以生成静态页面。
尽量写出好的和高效的SQL。
5.支付功能的实现?
答:
支付简单来说就是服务端集成相应的SDK,微信支付宝都有对应不同服务端语言的SDK代码，修改的只有少部分参数，然后定义需要的参数接口暴露给前端。用户点击下单以后，后端接收前端的参数，如用户id(一般支付从token获取)，商品id的集合等创建订单。价格一般是后端自己计算，并且需要使用bigdecima类型避免金额精度损失。然后服务端开启定时任务，一般30分钟，若用户未支付，定时任务会关闭该订单。
接着是支付，用户下单以后点击支付，后端会根据对应的订单id调用SDK接口，获取对应的url返回给前端，前端打开对应的url网页，微信支付宝会和后端建立socket，实时返回用户的支付情况，支付成功后会调用配置好的回调url，此时支付完成，前端第三方的支付网页自动重定向到之前配置的回调url，后端会在支付成功的钩子函数拿到提示，修改订单的支付状态，此时支付完成。
现在很多网站都是二维码付款，二维码网页一般自己提供，此时需要前后端建立websocket（ajax轮巡一般不采用），在用户支付完成后关闭该网页。
沙箱环境初始化配置
支付请求发起
支付回调处理
商品浏览 > 添加购物车 > 结算 > 计算商品总价 > 生成订单 > 选择支付方式 > 支付成功回调
用户在客户端提交订单 向服务器端发送请求
服务器返回支付地址，引导客户端跳转到支付地址
用户支付
支付成功，支付宝重定向到服务端预设的客户端地址，通知用户支付结果。 同时支付宝向服务端发送 post 请求（请求地址是提前设置好的）告诉服务器当前支付结果 ，服务端创建订单，根据支付结果修改订单状态（未支付、已支付）
支付宝流程
支付流程：先去调后台服务的支付接口，传递支付宝和服务端所需参数，服务端会返回一个支付宝支付页面链接，然后前端跳转到链接进行支付，支付完成支付宝会自动跳转到服务端定好的前端指定页面，支付即完成。
在用户在浏览器点击进入支付过程按钮后，会向网站服务器发送一个带有相关信息的请求，然后服务器会将订单所需要的信息和支付完成后跳转回来的地址一同向支付宝的服务器发送一个请求，然后会得到一个可以用来打开支付页面的url 地址。接着网站服务器会将这个url 地址返回给浏览器，此时浏览器就可以跳转到这个支付页面的支付宝的 url，待到支付完成后，支付宝的支付页面会跳转到之前服务器告知的返回页面，这样就又会回到自己的网站了。浏览器跳转回自己网站的同时，支付宝的服务器还会向网站服务器发送一个post请求，服务器接受到这个 post 请求就可以对订单状态进行处理了。
a. 客户端点击购买, 向服务端发送请求, 并入参相应参数
b. 服务端根据接收的信息, 校验通过后, 向支付宝下单, 并获取支付地址, 将该地址传回客户端
c. 客户端获取地址后, 跳转到该支付地址
d. 该地址为支付宝的地址, 在操作登录后(如果未登录), 支付订单
e. 支付宝收到支付请求, 校验通过后, 向服务端发送支付成功的通知, 服务端修改相应订单内容, 支付宝通知客户端支付成功
f. 客户端展示支付成功界面, 尔后跳转到购物车界面
6.sku 减库存
答:SKU = Stock Keeping Unit (库存量单位) 即库存进出计量的单位，可以是以件，盒，托盘等为单位。SKU 是库存量单位，区分单品。 在服装、鞋类商品中使用最多最普遍。 例如纺织品中一个 SKU 通常表示：规格、颜色、款式。在设计表时，不仅仅只有商品表，商品表中有个总库存，我们还需要涉及一张 SKU 表，里面有 SKU 库存和单价字段，用户每购买一件商品，实际上购买的都是 SKU 商品，这样在下订单成功后，应该根据所购买的商品的唯一的 SKU 号来进行相应的 SKU 库存的减少，当然商品的总库存保存在商品主表中，也需要减少总库存中的库存量。
