反省在北京某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、面试官提问:抢红包时如果因为用户并发量过大,出现了数据不一致怎么办

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

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

原文地址:https://www.cnblogs.com/renhongwei/p/8831382.html