项目架构：

Spring（3.5）、SpringMvc、Mybatis、Redis、Rocketmq 、Mysql

项目介绍：

商户通系统（app-kqs-m）主要是为门店管理者和收银员提供数据支持、门店的管理，同时也有收单功能的APP。后端接口主要分为用户模块、终端模块、门店模块和交易模块。其中用户角色有三类，管理员、店长、收银员，管理员是老板，管理多个门店，拥有所有门店的权限，店长是一个门店的管理者，只能管理自己所属的门店，收银员是最普通的角色，属于某一个门店的员工，权限有限。

项目职责：

1.负责app-kqs-m系统开发

项目总结：

1.商户通app设计之初本应当是一个提供给门店用户的经营管理型APP，用于商户和门店进行数据分析，结果硬是把收单功能也做了进去，不伦不类，一个用户可能既有收单终端又有通知终端，这样搞连我们自己研发都头疼，更别说用户了。而且动不动就按门店维度来推送，那火爆一点的门店里，他们的手机估计一天都会响个不停。

2.商户通比较麻烦的是两部分，用户和交易通知，而这两部分恰恰又是有关联的，你改了用户信息（无论是终端还是门店还是配置），才有可能触发交易通知的修改。

对于用户，要理解我们还是用MAM的账户体系，只是我们自己也存了一份用户信息，只是这份信息里基本都是不会改变的东西，因为MAM不会帮我们管理用户与门店、终端之间的关联关系；对于交易通知，首先，三种情况会有通知：1.收单终端，2.通知终端，3.关注门店（门店下的所有终端都算）；服务端是把这些信息维护在redis里的，结构是key-Hash(key-value)的形式，具体内容是terminalId-(userId-token)，注意，这个结构在redis里是不过期的。服务端会监听交易通知，然后根据terminalId判断是否是我需要的终端，如果在redis里存在，且Hash不为空，那么会去根据Hash里的内容做通知。所以只要涉及到终端、门店关注的修改，包括token注册、用户登出、推送选项的修改，一句话，只要涉及到交易通知的改动，都要去动缓存。