项目背景
该项目主要是用来给学校啦啦队进行投票，并结合当下比较火的在线答题而产生一款应用，因为我们的主要用户流量来自于微信公众号，所以该产品结合了微信公众号实现了相应的功能
项目需求
后台管理功能
- 实现啦啦队伍信息的上传
- 实现对于题目的增删改查
- 实现文件（视频，图片信息）的上传
用户功能
- 给对应的啦啦队留言，给留言点赞。不可重复点赞
- 每人每天可答五十道题目，根据正确的答题数目给啦啦队投票
- 答题时间为每天早晨的8：00-当天晚上8：00
- 答题非一次性答完所有题目
- 每道题目的思考时间为10秒钟
- 可以同时给多个队伍投票，投票成功后返回啦啦队所在战队的最新里程数
- 队所在战队最新的票数
页面展示
启动页面展示产品slogan和当天数据统计
- 每天下午五点以前显示产品slogan
- 每天下午显示当天数据统计，格式为：当天答题数目为：xx,超过xx%的用户； 当天获得的助力数为：xx,超过xx%的用户；当天为啦啦队增加的助力数为：xx,超过xx%的用户。
首页展示各个啦啦队的首页宣传图片，口号和介绍
- 要求每次进入页面时，啦啦队伍顺序随机
- 点击某个啦啦队伍的首页宣传图，进入这个啦啦队伍的详情页
- 详情页包含啦啦队伍的轮播图，宣传视频，啦啦队员的个人照片和留言信息
- 点击啦啦队员的照片，放大啦啦队员的照片，并显示啦啦队员的姓名和个人简介
- 页面下端显示啦啦队留言信息
战队排行榜页显示各个战队目前的分数和战队所具有的啦啦队
- 根据战队的分数进行降序排列
个人信息页面显示个人的微信头像，昵称，自己所具有的分数，自己的助力历史
- 助力历史显示自己总共为该战队的投票数，和当前该战队目前所具有的分数
- 个人答题榜页面显示根据答题正确数量最多的前十名用户，和当天的三名幸运用户。
- 每晚八点，系统自动根据当天答题的情况随机抽取三名幸运用户
项目信息
开发语言
- JAVA
数据库
- MySQL作为主要的数据库，Redis作为缓存数据库
项目构想
因为整个项目主要分为前台用户和后台管理，因为这次项目在上线过程中主要出现的问题主要集中在几个点，所以我将着重的介绍一下这些“坑”
获取幸运用户
其实刚开始看到这个需求的时候，自己还是比较蒙的，因为他涉及到一个在某一个特定的时间点就需要程序自启，刚开始自己的想法是通过多线程的方式去自启（如何通过多线程的方式去自启方法我将在java开发微信公众号部分将进行介绍和应用），后来查了相关资料发现，其实用listener实现该方法的自启才是最好的选择，在服务器部署的时候计算一个当前部署时间与晚上发布幸运用户的时间差，然后程序根据该时间差进行自启，并在一天以后再次自启。进入循环，从而实现了该功能
用户答题
这个地方会有多出涉及到一个Redis的数据类型的使用，如果对于Redis的使用还不是很清楚的同学可以看看我的另一篇博客Redis基本的数据类型和常用命令看看相关的介绍
- 获取题目
- 这个部分的需求主要是产品希望用户每天只能答50道题目，每十题增加一个难度，而且用户不是一次性答完50道题，用户可以随时退出，下次接着答。所以在这方面考虑到了对于数据库的压力，所以我采取的方法是在用户当天第一次进入答题时，一次性取出50道题目，题目按照难度排序，然后将题目写入Redis的HashMap中，并将所有答案单独存放在一个HashMap中，并设置有效时间为一天，每次根据用户已经答题的数目作为key，查询新的题目。当用户非当天第一次请求时，先判断用户当天的答题数目是否已经超过50题。
获取正确答案（即判断用否回答正确）
- 这一部分的需要注意的点就比较多：
1.我们需要判断用户传回来的questionId是否在当天给他抽取出来的50道题目中；
2.我们需要防止用户对同一道题进行重复的发请求（同一个数据重复发送50次，从而达到50题全对），所以我们需要对用户进行一个答过的questionId记录（这个地方我采用的是Redis的集合方式），再根据questionId获取正确答案之前在集合中先查询判断一下，如果已经答过（在获取题目时，会避免同一用户在当天答到相同的题目），则直接作为错误请求处理；
4.我们还需要对用户今日的一个答题数目进行判断（这个地方我采用的是Redis的String类型，其实完全也可以通过计算该用户的答题历史的集合元素个数实现）
5.根据前端传回来的questionId查询正确的答案返回给前端，判断用户是否正确，并将答题记录在mysql中*
- 这一部分的需要注意的点就比较多：
为啦啦队投票
- 这个需要注意的地方主要是一个点：
1.大家应该对于Redis有一个初步的了解那就是Redis其实是一个单线程的，所以，我们在对于判断前端传来的数据（因为可以同时投多个队伍，所以需要对用户所投的所有票数相加然后判断是否具有足够的投票数进行投票），就可以启动一个Redis的单线对于投票进行控制，防止同一个用户在上一次投票还未处理完，下一次请求就发起（例如：一个用户具有20票，他投了20票，当他第一次请求后，判断他是有足够的票数，他又发起第二次请求，如果第一次请求还未完成扣除票数的操作，那么该用户的第二次请求还是会判断为成功）
- 这个需要注意的地方主要是一个点：
项目反思
项目进度的安排
这一部分自己出现的问题主要是对于项目进度安排的不合理所造成的。因为产品那边提出相应的需求后，自己并没有思考一些需求是否具有其实际的使用价值。例如题目上传的部分，完全可以使用Excel导入的方法实现，完全没有必要开发相应的接口，其次自己前期主要花太多时间点着重于后台管理的开发，而忽略了这个项目其实真正的核心功能点在于用户提供答题为啦啦队助力，而不是后台管理界面的开发，所以在最后产品快要上线的前期，自己的核心功能点还尚未实现。所以建议各位在实际的项目开发方面，最好先权衡利弊，考虑一个项目的核心功能点在于什么地方
团队合作沟通方面
在这次项目的开发过程中，以及后来的测试中，出现最突出的问题就是和团队的沟通的不足。导致在后期的接口调试过程中出现了很多因为沟通不足而造成的错误，浪费了很多不必要的时间，所以建议各位在后面的项目开发方面加强和团队的沟通，毕竟一个项目不是一个人的事，好的沟通或许真的是成功的一半。
项目的构建
在这个地方，我觉得需要提醒的是我们在开发的过程中，尽量做到模块化的开发，尽量解耦和降耦，否则在后期的代码调试和需求的调整方面，将会十分的麻烦，自己就在这个项目上吃了很大的亏，浪费了很多不必要的时间，同时也可以提高代码后期的复用率；同时，对于数据库的设计方面，也可以根据实际项目的需求，合理的进行设计。没有必要完全按照范式的要求去设计，必要的时候可以进行一些字段的冗余，从而降低查询的难度和查询的时间；当然，还有对于项目的优化应该是建立在需求能够实现的基础上进行的，如果需求不能够实现，那么优化就是无稽之谈。这个地方，自己前期就花了太多的时间在答题的优化和对数据库压力方面，但是实际的项目并发没有想象中的那么大，所以完全可以等项目的基础功能实现之后再进行优化。
技术
这个其实也是限制自己这次项目的最大因素吧，因为个人的能力原因，对于一些设计模式的学习不足，在整个项目中，几乎看不到什么比较具有亮点的地方，更多的像在堆需求，同时，这个项目的过程中，出现的最大的问题，是自己在网上借鉴了一部分关于redis连接池的代码，这段代码在本地测试时没有任何的问题，但在项目上线后就立马出现了很大的问题，当时也没有即使的检测出来，导致项目的停滞，也是整个项目出现bug的最主要的因素。所以希望各位今后在开发的过程，如果涉及到了借鉴他人的代码，一定要做足相应的测试。同时建议各位多看看别人优秀的代码，从而提高自己的实际开发能力
本地开发和上线的模式区别
其实对于大多数开发仅限于本地测试的同学，其实难以区分自己本地测试和需要上线的项目的区别，其实在做这个项目之前，自在开发这个项目之前也没有很深刻的印象，但当本地测试通过，但在真正当项目部署服务器后，才回发现原来有很多的地方的不同，所以建议各位在开发前期，就准备好本地测试的配置和上线配置的切换，以及各位其实没有机会得到锻炼的小伙伴可以尝试去买一个服务器，自己尝试部署，来体验其中的不同。
以上就是自己对于这次项目所有的看法和新的体会，能力有限，尚存在诸多不足，望各位批评指正。
扫码关注作者个人技术公众号,有关技术问题后台回复即可，不定期将有学习资源分享