更新中
设计过程中
1、过度设计，自己添加功能，导致表结构设计不合理。
任何项目开发必须以需求文档描述的业务逻辑和功能为准，有建议可以提出跟产品沟通。
2、硬套规则
3、数据量预估不准确。
做活动一定要预估数据量（根据pv预估qps,根据uv以及活动时长预估活动总数据量），规划好数据库容量
qps计算
原理：每天80%的访问集中在20%的时间里，这20%时间叫做峰值时间
公式：( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS)
机器：峰值时间每秒QPS / 单台机器的QPS = 需要的机器
问：每天300w PV 的在单台机器上，这台机器需要多少QPS？
答：( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)
问：如果一台机器的QPS是58，需要几台机器来支持？
答：139 / 58 = 3
qps = 日活/86400*4
web安全
原则：输入-存储-展示 完全一致
前端数据检验,php接收严格校验,入库只需要做防SQL注入处理,返回前端做防xss攻击
sql防注入
根据1.magic_quotes_gpc配置情况决定是否调用addslashs(入库addslashs，出库stripslashs 正反配合使用不合理)
2.mysqli_real_escape_string 转义
3.绑定变量
后端对数据的有效性进行判断
3选1，不能重复使用
防范csrf攻击
方法一:Token 验证：（用的最多）
（1）服务器发送给客户端一个token；
（2）客户端提交的表单中带着这个token。
（3）如果这个 token 不合法，那么服务器拒绝这个请求。
方法二：隐藏令牌：把 token 隐藏在 http 的 head头中。方法二和方法一有点像，本质上没有太大区别，只是使用方式上有区别。
方法三、Referer 验证：Referer 指的是页面请求来源。意思是，只接受本站的请求，服务器才做响应；如果不是，就拦截。
XSS处理
输入只做放sql注入
数据在输出的时候PHP调用htmlspecialchars转义html标签
前端通过innerHTML或者$.html()展示数据 或者后端PHP不将标签转实体，前端用 $.text() 或者 innerText展示数据。
redis数据类型函数作用
待续
分库分表
使用水平分片,将用户按一定规则（按id哈希）分组，并把该组用户的数
据存储到一个数据库分片中，即一个sharding，这样随着用户数量的增加
，只要简单地配置一台服务器即可
一张用户和分片对应的数据表，每次请求先从这张表找用户的分片id，
再从对应分片中查询相关数据,通过这样的方法去获取签到记录和领取记录
1 hash、自增id取模：
对某个字段进行hash来确定创建几张表，并根据hash结果存入不同的表；
2 按时间
根据业务可以按照天、月、年来进行拆分；
3 按每个表的固定记录数
一般按照自增ID进行拆表，一张表的数据行到了指定的数量，就自动保存到
下一张表中。比如规定一张表只能存1-1000个记录；
4 将老数据迁移到一张历史表
比如日志表，一般只查询3个月之内的数据，对于超过3个月的记录将之迁移到
历史子表中；
并发处理
单用户并发:
用户模拟数据多次写入,先查询在插入更新的模拟并发
多用户并发:
乐观锁:
先采用update抢占数据,在数据表中添加版本号(version),根据版本号作为数据锁
悲观锁:
1.使用redis setnx(使用redis incl函数检验字段是否存在),给数据设置过期时间
使用setnx原子型操作加锁,设置过期时间，防止死任务的出现,就是setnx成功，但expire失败，这就可能存在死任务的情况。
解决这个问题的一种通用方法是通过使用incr方法代替setnx
使用incr原子型操作加锁,置过期时间，防止死任务的出现,当设置了最大加锁次数时，如果尝试加锁次数大于最大加锁次数并且无过期时间则强制解锁
2.---事务开始
1，查询商品表、锁定表：for update
2，判断商品库存是否大于购买数据，
3，如果库存满足，减少商品表库存。（不满足就回滚事务了。）
4，减少商品SKU表库存
5，记录订单操作记录等
--事务提交（事务提交时即释放锁）。
