项目问题整理

问题
ABTest 参考：	排序策略： 价格高低、单双多、促销、置顶   评估结果：卖品点击率（用户点击/页面总PV） 下单率（用户下单/页面总PV）   实验组：排序策略调整组      对照组：原始策略组 域 层
变更系统   WAIT_COMMIT(1, "待提交"), WAIT_AUDIT(2, "待审核"), AUDIT_PASS(11, "审核通过"), AUDIT_REJECT(12, "驳回审核"), ABOLISH(0, "删除");	// 是否有变更 boolean hasChange(ChangeVo srcObject, ChangeVo targetObject, List<String> ignoreProperties) // 变更合并 ChangeVo merge(ChangeVo srcObject) // 保存变更 ChangeCustomer saveChange(Integer customerId, ChangeVo srcObject, ChangeVo targetObject, List<String> ignoreProperties) // 提交变更 ChangeCustomer commitChange(ChangeCustomer changeContract) // 驳回变更 ChangeCustomer rejectChange(ChangeCustomer changeContract) // 变更审核通过 ChangeCustomer passChange(ChangeCustomer changeContract)
dealservice 模型升级	存在问题：商品模型太单一不利于数据的统计 例：统计某个套餐的销量、统计某些门店某种套餐的销量   SPU（关键属性） : 单品 + 数量单位 的组合   例 ： 2杯咖啡 ；1桶爆米花+2杯可乐 等 item （基本属性）: SPU + poi 的组合       例： 万达2杯咖啡 ； CGV2杯咖啡 SKU（销售属性）： 规格 + item 的组合    例： 万达2杯50ML咖啡；万达2杯100ML咖啡
SKU-SPU	以卖品为例，例如比较复杂的卖品套餐，1桶爆米花+2杯可乐 SPU：1桶爆米花+2杯可乐 SKU：（小桶，大桶）*（小杯，大杯）= 4个sku item：天堂电影院的1桶爆米花+2杯可乐
商品中台	只有公司需要开发大量相似业务的时候，才需要中台；   中台是站在业务群组上的概念，目的是为了支持新的业务快速上线&老的业务快速迭代
设计一个好的接口	职责原则 ：明确接口的职责，取名 见名知意   单一性原则： 一个接口只做一件事   协议规范： 用HTTP还是rpc，最好统一规定参数格式及响应格式   兼容性：可扩展性、稳定性   简洁性：容易阅读、维护起来简单、有接口文档、不要过度设计   安全性：接口暴露的考虑，接口并发量的考虑，接口防攻击的考虑   性能：能抗多大流量
接口性能测试及优化	1.是否为服务器硬件瓶颈？ CPU、内存、IO读写 falcon查看 如果是，就得通过加机器、扩内存来处理，也有可能是大量读写数据库导致的   2.网络瓶颈，可以通过查看网络利用率来确定，网卡的流量流入速度 falcon能查看 如果是，升级网卡   3.JVM的瓶颈，可以通过一些可视化工具进行查看GC情况 如果是，则dump 堆内存，分析出现GC日志   4.中间件瓶颈，可以通过个中间件的使用情况进行查看 如 redis、MQ、thrift等 如果是，看是都需要配置更多的资源，或者让中间件团队升级   5.应用的瓶颈 CAT查看调用链，耗时主要在哪，进行优化 优化方式 如：做降级处理、循环改成批量，让第三方接口升级，走缓存代替走库   6.数据库瓶颈 查看数据库的负载情况及是否有慢查询 优化方式 索引优化及缓存代替数据库
系统压测	压测平台： quake      监控 ： cpu、数据库、网络、接口qps 及 耗时，接口报警 压测数据：回放线上一段时间的真实数据 写压测难点： 特殊标记来标识压测流量 （基础组件都得升级，RPC 、HTTP、缓存、MQ）；数据的存储形式，不能让压测数据污染线上数据库（带压测标的数据要写入线上影子库）   压测步骤： 1.梳理压测接口调用链路 用户中心（鉴权）、价格计算系统（促销价格计算）、库存中心（查看库存）、优惠券系统（可用优惠券列表）、商品中心（获取商品信息） 2.相关系统组件升级 （RPC 、HTTP、缓存、MQ） 3.压测数据准备 （回放线上一段时间的真实数据） 4.小流量验证写数据是否到库存里面去了 mysql 、tair、MQ   压测结果： 问题 1 ： 促销、优惠 、库存服务超时 降级相关服务   问题2： 商品出现 CUP利用率极高，数据库连接数飙升、服务拒绝请求 原因：凌晨有定时任务全量请求库存，批量刷缓存，且缓存集中失效 方案：调整缓存失效时间点和数据库刷库时间点   问题3： 商品中心某些机器负载明显高于其他机器，导致流量分部不均匀 原因：同机房优先调用原则 解决方式：关闭同机房调用策略，且没个机房申请相同数目的机器
商品展示系统接口	查询列表、查询详情、查询影院小吃标、查询影院商品Id 等等
tomcat 调优	Connector : 连接器的配置 bio、nio 和 apr   maxThreads: Tomcat 可创建的最大的线程数 默认值是 200   minSpareThreads : 最小空闲线程数，Tomcat 启动时的初始化的线程数，表示即使没有人使用也开这么多空线程等待，默认值是 10   connnectionTimeout : 连接超时   URIEncoding ： 字符集 UTF-8
系统设计 -- 秒杀系统设计	秒杀系统独立，集群独立部署 热点数据单独放缓存系统，也可做本地缓存，提高读写，数据做动静分离 静态热点数据获取；动态热点数据收集 增加秒杀答题，防抢单 增加限流、降级   一致性减库存： 下单减库存、付款减库存、预扣库存   如何保证库存不为负数？ 通过事务来判断；设置数据库的字段数据为无符号整数；使用 CASE WHEN 判断语   秒杀减库存的极致优化 减库存直接放到缓存系统中实现 （如果扣库存逻辑比较简单）
系统设计 -- 订单系统	订单号：唯一性   订单数据：订单基本信息、支付明细、优惠明细、订单状态（待付款、待消费、已完成、退款中）   系统定位：负责订单主状态的流转、提供订单通用数据存储
项目中遇到过什么问题？