一、你在项目开发中遇到过哪些问题？

此问题的回答一般从三个方向入手，一是技术问题，二是解决方案问题，三是甲方或团队配合问题，针对这三个方面的问题回答示例。

一、技术方面：
开发项目过程中遇到问题是难免的，但是面试中绝对不可以暴露低级的bug，博主小白在职期间经常遇到的问题：
1.本地环境与线上环境出现问题不一致，可能是线上环境问题，运维部署服务器问题等。
2.线上数据库版本问题，导致本地写的sql到线上不支持该语法报错。
3.第三方支付问题，客户提供的信息有误，平台未绑定等等影响的。
4.事务问题，方法未执行完就走其他功能，导致程序混乱，加上事务注解，放在biz层。
5.页面，手机兼容问题，跨域问题等等。

下面给举几个例子，总结成自己的描述绝对没问题啦~

问题：我之前在项目开发中碰到过dubbo调用远程服务失败的问题，服务写好自测时无问题，在远方服务上打debug，被dubbo调用时显示可以进入程序就是显示调用失败。
解决方案：花了很多时间排查dubbo调用没问题后，我在服务端加了log4g方便看服务端的日志，然后发现服务端显示数据库无法连接，说密码有问题，我核对后发现密码没问题，但是我发现项目的mysql的数据库密码是初始密码没改过，mysql的root账户并没有开放远程连接的权限。所以我进入mysql服务中新加了一个root账户，改了不一样的密码，把项目中连接数据库的账户改为新加的账户，重启所有服务后就解决了。

二、解决方案：
问题：并发注册问题
我们在做完功能之后，对首页上所有功能做了并发性能测试，结果测出在做注册功能时会碰到同一个用户名或者手机号在并发量高的情况下会出现多次注册的问题。

我们的需求要求每个手机号或用户名只能被注册一次，在用户注册填写用户名手机号时会通过ajax去后台异步校验是否有重复记录，在并发情况下，会出现多个注册用户同时去后台校验一个未被注册的用户名时，都会成功通过，从而导致注册的用户名或者手机号重复。
解决方案：利用redis来解决，用户输入用户名去后台校验一旦成功，首先去redis中查看是否有这条用户名，如果有，则视为此用户名被别的用户抢占了，如果没，就放进去，然后返回校验成功。在别的用户去redis找这条数据只能排队去查时都能查到，视为用户名被抢占了，返回用户名校验不通过。

三、和甲方沟通问题
我们在做完一个功能模块后甲方需求变动了，所以我们只能硬着头皮改代码，连续加班半个月，这个事情本来可避免的，如果我们最初能在和甲方对需求的时候能挖掘他们的潜在需求，早点给他们一些正确的需求建议，这个问题可能就不存在了。

四、项目成员配备问题
企业开发项目中根据项目规模、周期决定项目成员配备情况，一般来说规模较小的项目人员配备比较少，小到甚至一个人负责开发一个项目，规模庞大的项目如京东物流，40多人开发一个项目。但我们做的项目大部分是 中小型的，团队一般为10人左右。在二三线城市一个项目组一般有核心成员和外围成员，核心成员就是项目经理和后台功能开发人员，后台人员一般都可独立完成功能模块，项目中一般有3-5个后台开发，其他的人员如测试、前端、实施、运维、数据库人员一般都是公用的，哪个项目需要就去哪个项目。

人员配备及项目规模相关回答：
这些问题的答案都是基于项目需求的。举个例子：

我们这个项目最初在和甲方对接时，甲方要求这个项目第一阶段开发完成后要满足每秒2000访问不卡顿，不出重大错误，结合项目的业务量，开发周期6个月，对项目的定位是第一阶段做一个中小型规模的平台。得到以下信息：项目定的目标并发量为2000，根据业务难度和业务量，成员配备如下：项目经理一名，业务人员（产品）一名，后端开发人员4人；前端辅助开发人员1名，测试1-2人，网络机房管理人员一名，运维实施人员1人。 项目。刚上线的项目实际访问量一般都很小，按日统计，没没大规模推广的情况下，每日访问量1000左右已经不算低了。 项目部署：一般都是初期是中小型的，但是我们是做成分布式的系统，后期如果用户量和数据量增大时，我们可以弹性的部署，增加服务器数量，目前满足2000访问并发的一个分布式电商，首页部署10+1个tomcat，搜索部署5+1个tomcat，购物车2+1，订单2+1，支付1+1，秒杀10+1，运营商1+1，得注意的是并不是非得一个tomcat就得占用一个服务器，部署了商家系统的服务器还可以再部署个购物车或者安装个reidis，最后通过各系统占用网络资源的瓶颈，通过一些算法得出最优的部署方案。当然，如果你实在不知道部署，就说这是运维的事。