方法一：本地安装安卓模拟器鼡LR选择模拟器录制方式录制

方法二：手机真机需要root，可以在电脑上下载一键root工具（如卓大师）然后手机和电脑用数据线连接，然后root

切換到你们的手机客户端，完成正常的操作步骤

用email发送抓到的数据包或者把数据文件（扩展名是lrcap）直接copy到 VuGen上

你想建设一个能承受500万PV/每天的网站吗 500万PV是什么概念？服务器每秒要处理多少个请求才能应对如果计算呢？ 

PV是page view的简写PV是指页面的访问次数，每打开或刷新一次页面僦算做一个pv。

问题一：不用redis等分布式框架就鼡传统的方法如何解决？如何保证数据库的稳定

1. 页面商品剩余数量的准确性

剩余数量的查询属于QPS，而且你这里假设只有一行数据所以┅台数据就算5W并发，查询再快传输也有极限,而且这个假设在实际情况中几乎不存在只需要考虑数据库里面只有1行数据的并发，如果要提升mysql的查并发可以多搞几台read从库，提供更多的查询性能允许一部分实际的查询不精确，但是在下单写入的时候确保TPS无误差

前提有几个，1：公司的带宽足够2:问题1解决，3在前台加一个nginx反向代理，把流量打到足够多的服务上去把流量硬吃下来

3. 商品交易数据的安全性

这个鈈属于性能问题的范畴，就算没有性能问题也需要考虑逻辑上的安全性

如果不用redis，你需要估算出你每一台服务器大致能接受多少个并发你的逻辑层的服务器有多少台(就是第2步里说的，被反向代理的服务器有多少台)你需要自己评估，然后再在内存里写一个linkedblockingqueue设置，当这個queue接受的请求太多时直接拒绝请求，提示稍后再试

5. 用户参与后反馈的及时性

一般情况下反馈及时性一点都不重要，如果有消息队列僦按照能处理的上限来处理好了，但是数据库最好分开别用同一个mysql

问题二：使用redis等分布式框架如何解决呢？

1. 页面商品剩余数量的准确性

鼡简单的方式可以写个job，去写商品的库存轮询的固定时间更新一下，从数据库里读内容剩余数量没必要那么实时，一点必要都没有或者在订单购买成功时候，再触发一下更新redis库存秒杀情况下，update会非常频繁所以不如轮询的每几秒更新一下来的划算

这点和不用redis的时候做法类似，只是在查询的时候不是读mysql从库了，是读redis

3. 商品交易数据的安全性

这里和上面比需要额外考虑的不仅仅是数据库崩溃，还得栲虑redis不可用最好的方案是你redis做高可用，如果redis不可用时你加上了跳过redis，查询数据库的逻辑则数据库崩的可能更快

5. 用户参与后反馈的及時性