上次说了商品,商品分类,品牌,分类的属性,规格。很多电商网站例如:京东,国美,苏宁他们的商品都是存储在redis中的,通过请求获取到的redis进行js的渲染动态的展示商品的信息。
源码:https://github.com/limingios/netFuture/tree/master//源码/『互联网架构』软件架构-解密电商系统营销-会员模块业务(72)/
		
	
		
	
		
	
营销活动
> 商品的ID,营销工具的ID,营销工具的编号,营销工具的类型(商品级别的,订单级别的,全站级别的),渠道(PC端的,IOS端的,android端的)
		
	
营销活动对应的订单数据
> 针对营销活动产生的订单
		
	
营销技术方案
> 1个用户或者一个商品对应1-3个营销活动,1万个商品(购物车)就有3万个营销活动如果持久化到mysql上,mysql肯定是受不了的。如果是100个用户,双十一必须挂了服务。
优化方案(缓存,redis也会有问题。redis里面存3万多条数据,浪费了大量的网络资源)
解决方案是:类似新华字典一样,redis里面针对某个活动只存储key值,内容保存在JVM cache中。因为目前都是存在JVM中,如果是分布式同步下,需要使用zookeeper。
		
	
####(二)会员模块
电商里面最复杂的就是商品,最简单的业务就是会员。
* 业务
会员模块用户注册、登录、找回密码、积分业务
技术点:会员SSO、分库分表
>单点登录。1.session如何存储的(redis)
		
	
单点登录。2、服务端如何获取你信息?Token(客户端跟服务端 包含登录)
sale.jd.com登录 item.jd.com(我不知道你登录)
登录后把token放入redis中作为key,token的信息保存在cookies中,当访问在item.jd.com后,通过cookies里面的token来确认用户是否登录。
分库分表。hash取模、list预定义、range范围,具体都是通过shardingjdbc处理的
说说之前的公司关于会员表一共8个库,后来变成了16个库。这个是如何处理的。
1.当时8个库的分库思路是通过hash取模的方式。(每个库800万数据)
2.如果改成16个库,凌晨进行处理,先将数据进行处理分为:待迁移%8、 (服务可用)迁移中(%8) 、迁移完(%16),通过copy的方式。2个小时搞定的。
3.迁移完后进行取模改成16。停机2个小时。
4.当时同事提出不停机,如果在这个期间会员信息发生修改,通过binlog的方式在新迁移的信息通过binlog的方式在新迁移的库中执行,因为比较麻烦后来放弃了。
5.直接停机2个小时。前提这些都是在测试环境测试过了。迁移完后等于2份,一个在0库,一个在16库,删除原来0库中的数据。
表设计
>t_account会员表
| 参数 | 名称 | 类型 | 主键 | 唯一 | 
|---|---|---|---|---|
| id | 会员ID | int | Y | |
| nickname | 昵称 | varchar | y | |
| account | 用户名 out 当前时间戳 | varchar | y | |
| password | 密码 | varchar | ||
| accountType | 会员类型。qq,sinawb,alipay | String | ||
| trueName | 真实姓名 | String | ||
| sex | 性别。m:男,f:女,s:保密 | String | ||
| birthday | 出生年月日 | Date | ||
| province | 省份 | String | ||
| city | 所在城市 | varchar | ||
| address | 联系地址 | varchar | ||
| postcode | 邮政编码 | varchar | ||
| cardNO | 证件号码 | varchar | ||
| cardType | 证件类型 | varchar | ||
| grade | 等级 | int | ||
| amount | 消费额 | money | ||
| tel | 电话 | varchar | ||
| Email地址 | varchar | y | ||
| emailIsActive | 邮箱是否已激活。y:已激活,n:未激活。默认n | String | ||
| freeze | 是否冻结 n:未冻结,y:已冻结;默认n | String | ||
| freezeStartdate | 冻结的开始日期 | Date | ||
| freezeEnddate | 冻结的结束日期 | Date | ||
| lastLoginTime | 最后登录时间 | Date | ||
| lastLoginIp | 最后登录IP | String | ||
| lastLoginArea | 最后登陆地点 | String | ||
| diffAreaLogin | 是否是异地登陆y:是,n:否 | String | ||
| regeistDate | 注册日期 | Date | ||
| addressID | 配送信息ID | Int | ||
| openId | QQ登陆返回 | String | y | |
| accessToken | QQ登陆返回 | String | ||
| alipayUseId | 支付宝快捷登陆返回的用户ID | String | y | |
| sinaWeiboID | 新浪微博登陆返回的用户ID | String | y | |
| rank | 会员等级。和t_accountType.code进行挂钩。默认R1 | String | ||
| score | 会员积分。默认0 | Int | 
t_accountRank会员级别表
| 参数 | 名称 | 类型 | 主键 | 
|---|---|---|---|
| id | 自增 | int | 是 | 
| code | 级别编码R1:普通会员,0-499R2:铜牌会员,积分范围500-999R3:银牌会员,1000-1999R4:金牌会员,2000-4000R5:钻石会员,大于4000 | String | |
| name | 级别名称 | String | |
| minScore | 最小积分 | Int | |
| maxScore | 最大积分 | Int | |
| remark | 备注 | String | 
t_address配送地址信息表
| 参数 | 名称 | 类型 | 主键 | 
|---|---|---|---|
| id | 自增 | Int | 是 | 
| account | 会员账号 | String | |
| name | 收货人姓名 | String | |
| province | 省份 | String | |
| city | 城市 | String | |
| area | 区域 | String | |
| pcadetail | 省市区的地址中文合并 | String | |
| address | 收货人详细地址 | String | |
| zip | 收货人邮编 | String | |
| phone | 收货人电话号码 | String | |
| mobile | 收货人手机号码 | String | |
| isdefault | 是否默认;n=不是,y=默认 | String | 默认n| | 
很多系统的权限这块 公共。权限系统一般有:账号、角色、权限、资源。
权限可以分为三种:页面权限,操作权限,数据权限。
在互联网公司有个专业术语:权限这块防小人(不懂电脑的),防君子(IT人员)
控制你可以看到哪个页面,看不到哪个页面。
很多系统都只做到了控制页面这一层级,它实现起来比较简单,一些系统会这样设计,但是比较古板,控制的权限不精细,难以在页面上对权限进行更下一层级的划分。
则控制你可以在页面上操作哪些按妞。
延伸:当我们进入一个页面,我们的目的无非是在这个页面上进行增删改查,那在页面上对应的操作可能是:查询,删除,编辑,新增四个按钮。
可能你在某个页面上,只能查询数据,而不能修改数据。
数据权限则是控制你可以看到哪些数据,比如市场A部的人只能看到或者修改A部创建的数据,他看不到或者不能修改B部的数据。
延伸:数据的控制我们一般通过部门去实现,每条记录都有一个创建人,而每一个创建人都属于某个部门,因此部门分的越细,数据的控制层级也就越精细,这里是否有其他好的方式除了部门这个维度还有其他什么方式可以控制数据权限。
| 参数 | 名称 | 类型 | 备注 | 
|---|---|---|---|
| id | 自增长 | int | 唯一 | 
| username | 帐号 | String | 唯一 | 
| password | 密码 | string | MD5加密 | 
| createtime | 创建时间 | String | |
| createAccount | 创建人 | String | |
| updatetime | 最后修改时间 | String | |
| updateAccount | 最后修改人 | String | |
| status | 状态 | String | y:启用,n:禁用;默认y | 
| rid | 角色ID | Int | |
| nickname | 昵称 | String | |
| 邮箱 | String | 
| 参数 | 名称 | 类型 | 备注 | 
|---|---|---|---|
| id | 自增长 | int | 唯一 | 
| role_name | 角色名称 | String | |
| role_desc | 角色描述 | string | |
| role_dbPrivilege | 数据库权限 | String | |
| status | 角色状态,如果角色被禁用,则该角色下的所有的账号都不能使用,除非角色被解禁。 | String | y:启用,n:禁用;默认y | 
| 参数 | 名称 | 类型 | 备注 | 
|---|---|---|---|
| id | 自增长 | int | 唯一 | 
| rid | 角色ID | int | |
| mid | 资源ID | int | 
| 参数 | 名称 | 类型 | 备注 | 
|---|---|---|---|
| id | 自增长 | int | 唯一 | 
| pid | 父ID | Int | |
| url | 资源 | String | |
| name | 资源名称 | string | |
| orderNum | 序号 | int | |
| type | 功能类型 | String | module:模块page:页面button:功能 | 
大型网络公司内部使用的,建议内部粉丝专用,这里不做演示,详细使用建议联系我。
源码:https://github.com/limingios/netFuture/tree/master//源码/『互联网架构』软件架构-解密电商系统营销-会员模块业务(72)/
1、存储在jvm的对象可视化 可以操作
2、调试bug比较有用 查看最新代码
3、给系统留后门(生产 不需要重启机器可以改配置 )
		
	
<dependency>
            <groupId>com.gome.spring.compents</groupId>
            <artifactId>dynamo</artifactId>
           <scope>system</scope>
           <systemPath>${basedir}/../dynamo.jar</systemPath>
           <version>0.0.1-SNAPSHOT</version>
        </dependency>
        <dependency>
            <groupId>org.apache.commons</groupId>
            <artifactId>commons-lang3</artifactId>
            <version>3.7</version>
        </dependency>
	<servlet>
        <servlet-name>springdyn</servlet-name>
        <servlet-class>com.gome.spring.compents.servlet.DynServlet
        </servlet-class>
    </servlet>
    <servlet-mapping>
        <servlet-name>springdyn</servlet-name>
        <url-pattern>/dyn/admin/*</url-pattern>
    </servlet-mapping>
	访问方式
> http://ip:端口/项目名称/dyn/admin
> 用户名:admin
> 密码: admin
		
	
PS:今天说了营销的设计思路:营销工具,营销活动,营销活动订单。 会员管理:单点问题,会员信息session共享问题。权限问题:页面权限,操作权限,数据权限。黑科技:动态aop控制工具。
>>原创文章,欢迎转载。转载请注明:转载自,谢谢!>>原文链接地址:上一篇:已是最新文章