反省在北京某S2B2C电商小型公司面试时掉链子的问题

昨天，参与北京一家公司面试时，不知道为什么，错了很多题，这些题在该家公司之前已经被问很多次了，当天精神恍惚的没答上来或答错，被问到数据库优化和乐观锁的问题，首先我谈到了存储引擎底层的数据结构

B树/B+树：

B树是红黑树的变种数据结构，红黑树是一种自平衡二叉查找树，有其 左右子树 按序排列的特点，左小右大的特点，红黑树我没有做过深入的研究，只是背住了特点，等过去这段时间好好研究一下

关于B树与B+树请查看园友的详细总结：https://www.cnblogs.com/George1994/p/7008732.html

谈到数据库优化，首先会想到索引，而数据库索引则用到了B树数据结构，因B树数据结构存在关键字，所以在全键名匹配方面，访问速度会非常快，但索引若使用不当也会造成数据库性能的损失。

mysql数据库：

myisam：采用锁表策略，不适用在高并发场景，由于内部采用B树数据结构，所以匹配搜索非常快

innodb：采用行锁策略，适合用在高并发场景，多线程竞争时，只锁定竞争那一行数据

1、面试官提问：在程序代码方面什么情况下会使索引失效？

其实这题我之前已经回答过很多次了，可能面试官提问的逻辑跟之前不太一样，我没有听明白，这题没答上来，其实在写sql时我们需要注意：

在使用innodb存储引擎时OR与索引不可同时存在，否则索引失去效果，会进行全表扫描

具体可以看这篇文章：http://www.cnblogs.com/yuerdongni/p/4255395.html

另外使用 like 也会造成全表扫描

2、面试官提问：在基于你博客中的高并发乐观锁方案上，如果发生网络堵塞导致最终version不一致怎么办？

这道题我一开始回答的是从流量控制方面避免这种事情发生，后来想了想，我当时没能理解他的问题，现在也没怎么理解

实现乐观锁即CAS原理，假设下单减库存场景，先获取版本号，然后走业务逻辑，最终提交时比对一下版本号是否一致，他是不是说的这个时候网络阻塞，如果这个地方没能成功的从数据库取出版本号，只要不设置默认值，应该会抛出连接异常，在上游拦截处理美化之后提醒用户下单失败。

3、面试官提问：抢红包时如果因为用户并发量过大，出现了数据不一致怎么办

这个问题我可能回答的答案他并不满意，在我之前做的几种方案中已经解决了这个问题，如果真的要说百万级，这个流量非常恐怖，我当时提到了使用消息队列来削峰，延时处理，用户操作之后不会立即返回结果，只是告诉用户参与成功，用户可以到个人中心看进度，等消息队列消费之后更改状态，不过看面试官反应应该回答的不是他想要的，这个希望园友帮我出出主意

另外因为学历问题最近几天确实很郁闷，回忆起这家公司的笔试题，我错了两三道，还都是我之前答过的，也有一些的确我没有关注到的知识点，加油吧，希望这个城市能给我一些机会。