我要做的第一件事就是为API创建文档.

有文档后,您可以绘制项目的需求.你所写的东西是某种要求,但过于抽象,太大了.

当您有需求时,您开始考虑软件工程和结构.

在这一步中,在我看来,将事情分开是要走的路.这将使事情更容易管理.找到瓶颈错误,等等.

我不知道你的系统会触发“如果用户应该收到徽章”.所以我采用foursquare比喻.

公平地说,这些人正在做出惊人的工作来实时处理所有这些请求.我的意思是,看起来他们正在检查我是否应该在每次请求时收到徽章.因此,我的检查是在服务器端触发一些算法来检查我的签到和徽章历史,徽章规则,将它们组合在一起,创建我应得的徽章并显示我的新徽章作为回应.听起来很对吗？好吧,它是！

我不相信他们正在并行完成所有这些工作.这对服务器来说太过分了.虽然,我的四方徽章没有与任何其他用户交互(更容易),因此并行处理并非不可能.

首先想一想foursquare如何运作.负载均衡器将我的请求转发给不重负载的服务器.并且所有工作都是在paralel中完成的.负载越多,服务器启动的越多.仅使用从属数据库即时进行徽章的所有计算.向用户呈现他的徽章并将此数据发送回主数据库.这是可能的,因为徽章不会在不同用户之间进行交互.一个徽章 – 需要一个用户历史记录.

另一种解决方案是使用map – reduce.使用消息代理并行处理徽章审核.您收到了请求.发送消息给消息代理.消息在multiple workers登陆,其中一个工作人员仅针对用户历史记录检查一个特定徽章规则.最后,计算速度会快得多.

关于db结构.我认为没有办法通过所有数据库来确定用户是否应该收到徽章.我会采用简单,直接的方式来处理这个问题.只需使用外键,正确的列类型,正确位置的索引创建良好的结构化数据库,您就可以了.建立稳定的基础,并在需要时进行优化.

如果你真的渴望在项目开始时进行优化(我认为这是一个坏主意),我会将所有徽章相关数据保存在单独的表中.一个表格用于一个徽章,其中包含与该徽章相关的所有特定列.

示例是：badge_restaurants(user_id,badge_id,current_level,checkin_count).要获得新的餐厅徽章,您只需要检查用户是否确认checkin_count 1> =需要数量,您可以不再查看.

当然,这不是完美的解决方案.可以添加更多抽象以更复杂的方式完成(不创建数百个表).更复杂的徽章仍然会促使您创建更复杂的解决方案.