电商网站制作项目描述 第1篇
会员注册：客户端（移动端、PC端）调用会员服务注册接口进行会员注册，使用NatApp进行内网穿透，利用开源框架WxJava框架进行二次开发，会员先关注公众号，在公众号号接收验证码，并把验证码缓存Redis中，有效期3分钟，会员注册校验验证码是否一致，同时会员注册密码加盐加密MD5和BASE64散列存储。
会员认证：使用XXL-SSO框架实现微服务平台单点登陆开发，搭建并二次开发XXL-SSO的中央认证服务器，改造认证服务器的认证界面，同时植入认证验证码功能，整合各个门户例如首页频道、搜索频道等SSO客户端。基于cookies实现，虽然 cookies本身不跨域，利用XXL-SSO框架实现跨域的进行SSO认证。
广告管理：运营商广告类别管理、广告管理，使用七牛云进行广告图片分布式存储。首页频道服务广告的数据使用Redis进行缓存预热，开发并设计广告缓存系统设计，使用延迟双删、以及RabbitMQ缓存清除重试保证Redis缓存一致性。
订单管理：开发并设计下单流程，使用Redission实现分布式锁防止库存超卖，使用开源框LCN进行事务的一致性操作，保证商品服务减库存，订单服务新增订单。使用雪花算法进行在高并发分布式全局订单ID的生成.
电商网站制作项目描述 第2篇
购物车与登录模块/订单模块/用户模块/等模块交互
购物车考虑的点很多,比如
我们规定购物车必须要先登录才能使用
经过一个拦截器,根据token判断用户是否登录,如果登录判断Token是否过期,未登录以及过期的提示登陆
账户退出之后,购物车内容必须保存起来(mongoDB)---(直接使用mongo命令连接数据库---创建时，直接使用use [database]命令即可--查看当前数据库：最简单的命令就是()--直接通过(),()命令来保存数据)
mongodb简介: MongoDB是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。它支持的数据结构非常松散，是类似json的bson格式，因此可以存储比较复杂的数据类型。Mongo最大的特点是它支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数据库单表查询的绝大部分功能，而且还支持对数据建立索引。
购物车页面要能够显示商品的详细信息(商品名称、链接、数量、单价、总价)
商品分spu表和sku表,分别代表公共信息和规格信息,详细信息数据可以从sku里面获取
多条商品能够以列表显示；
用hash数据结构保存,购物车 用每个用户一个大key,小key1保存商品名字+数量,value1保存数值,小key2保存商品名+info,vlue2保存json 然后,抽出各个用户中的小key2,存在一个公共的大key里面,保存的时候用hsetnx指令(不存在就从数据库中拿过去保存,有值就什么都不做)
修改删除功能 : 能够调整商品的数量//移除购物车中的商品；
购物车能够添加50件不同的商品；
如果使用优惠券，结算价格相应调整;
购物车中的商品结算后，从购物车中清除；
限购商品数量不能超过限购数量,购买完成后不能再次添加购物车,不限购的不能超过库存；
电商网站制作项目描述 第3篇
该项目是基于SpringBoot/SpringCloud为重庆澳欧惠品构建的一款本地B2C新零售电商平台，客户通过前台浏览和购买商品，管理员通过后台对平台、商品、用户进行管理。主要出售日常百货，地区特产项目使用分布式框架,涉及后台管理员服务、地址服务、物流服务、广告服务、商品服务、商品类别服务、品牌服务、订单服务 、购物车服务、首页频道服务、公告服务、留言服务、搜索服务、会员服务等。
电商网站制作项目描述 第4篇
调优工具
sysbench：一个模块化，跨平台以及多线程的性能测试工具 iibench-mysql：基于 Java 的 MySQL/Percona/MariaDB 索引进行插入性能测试工具 tpcc-mysql：Percona开发的TPC-C测试工具
1 max user connection(设置最大连接数)
最大连接数，默认为0无上限，最好设一个合理上限thread_concurrency：并发线程数，设为CPU核数的两倍
2 back_log (MySql的连接数据达到maxconnections,多少个请求可以被存在堆栈中)
backlog值指出在MySQL暂时停止回答新请求之前的短时间内多少个请求可以被存在堆栈中。也就是说，如果MySql的连接数据达到maxconnections时， 新来的请求将会被存在堆栈中，以等待某一连接释放资源，该堆栈的数量即backlog，如果等待连接的数量超过backlog，将不被授予连接资源。可以从默认的50升至500
(数据库连接闲置时间)
数据库连接闲置时间，闲置连接会占用内存资源。可以从默认的8小时减到半小时
skipnameresolve
禁止对外部连接进行DNS解析，消除DNS解析时间，但需要所有远程主机用IP访问
keybuffersize
索引块的缓存大小，增加会提升索引处理速度，对MyISAM表性能影响最大。对于内存4G左右，可设为256M或384M， 通过查询show status like’keyread%’，保证keyreads / keyreadrequests在以下最好
innodbbufferpool_size
缓存数据块和索引块，对InnoDB表性能影响最大。通过查询show status like ‘Innodbbufferpoolread%’， 保证 (I – I)/ I 越高越好
InnoDB存储引擎用来存放数据字典信息以及一些内部数据结构的内存空间大小，当数据库对象非常多的时候，适当调整该参数的大小以确保所有数据都能存放在内存中提高访问效率， 当过小的时候，MySQL会记录Warning信息到数据库的错误日志中，这时就需要该调整这个参数大小
innodblogbuffer_size
InnoDB存储引擎的事务日志所使用的缓冲区，一般来说不建议超过32MB
querycachesize
缓存MySQL中的ResultSet，也就是一条SQL语句执行的结果集，所以仅仅只能针对select语句。当某个表的数据有任何任何变化， 都会导致所有引用了该表的select语句在Query Cache中的缓存数据失效。所以，当我们的数据变化非常频繁的情况下，使用Query Cache可能会得不偿失。 根据命中率(Qcachehits/(Qcachehits+Qcache_inserts)*100))进行调整，一般不建议太大，256MB可能已经差不多了，大型的配置型静态数据可适当调大.
可以通过命令show status like 'Qcache_%'查看目前系统Query catch使用大小
readbuffersize
MySql读入缓冲区大小。对表进行顺序扫描的请求将分配一个读入缓冲区，MySql会为它分配一段内存缓冲区。 如果对表的顺序扫描请求非常频繁，可以通过增加该变量值以及内存缓冲区大小提高其性能
sortbuffersize
MySql执行排序使用的缓冲大小。如果想要增加ORDER BY的速度，首先看是否可以让MySQL使用索引而不是额外的排序阶段。 如果不能，可以尝试增加sortbuffersize变量的大小
readrndbuffer_size
MySql的随机读缓冲区大小。当按任意顺序读取行时(例如，按照排序顺序)，将分配一个随机读缓存区。进行排序查询时， MySql会首先扫描一遍该缓冲，以避免磁盘搜索，提高查询速度，如果需要排序大量数据，可适当调高该值。 但MySql会为每个客户连接发放该缓冲空间，所以应尽量适当设置该值，以避免内存开销过大。
record_buffer
每个进行一个顺序扫描的线程为其扫描的每张表分配这个大小的一个缓冲区。如果你做很多顺序扫描，可能想要增加该值
threadcachesize
保存当前没有与连接关联但是准备为后面新的连接服务的线程，可以快速响应连接的线程请求而无需创建新的
table_cache
类似于threadcachesize，但用来缓存表文件，对InnoDB效果不大，主要用于MyISAM
第一范式（1NF） 在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。 所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。(出现重复的属性,重新定义一个实体,建立一对多的关系)如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式（1NF）中表的每一行只包含一个实例的信息。
2 第二范式（2NF） 第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一区分。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。 第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。简而言之，第二范式就是非主属性非部分依赖于主关键字。 3 第三范式（3NF）
满足第三范式（3NF）必须先满足第二范式（2NF）。简而言之，第三范式（3NF）要求(在一对多关系里面,除了主键不要再另外存别的信息)一个数据库表中不包含已在其它表中已包含的非主关键字信息。例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。简而言之，第三范式就是属性不依赖于其它非主属性。