-
-- 存储过程 (只在银行被大量的时候,互联网公司用的很少,但是在秒杀中用) -- 1.存储过程优化: 事务行级锁持有的时间 -- 2.不要过渡依赖存储过程 -- 3.简单的逻辑可以应用存储过程 -- 4.QPS:一个秒杀但6000/qps查看全部
-
调整源码顺序即可实现 将insert的顺序放在update的前面，因其不会有行级锁，是可以并行的 持有行级锁是在update上,释放锁是在commit(spring控制)，也就是锁持有时间是update和commit之间的时间。这个过程网络请求越少，锁持有时间就越短查看全部
-
运行结束后 redis中得到了一条测试数据 并且是序列化过的二进制数组查看全部
-
redis拿到了后端缓存中的数据,而不用去再次访问数据库 降低数据库访问量 一般情况下 秒杀单是不让改的,如果需要改,废弃掉,新建一个秒杀单 开发中,一套redis缓存一般都是一个集群,也不会想这样这么简单查看全部
-
开发环境中 redis的配置应该在.proerties中查看全部
-
这样序列化 要比原生序列化空间压缩了十分之一或者五分之一 压缩速度是两个数量级的快 同时节省cpu查看全部
-
序列化的本质 - 通过字节码和字节码对应的对象有哪些属性,把字节码的数据传递给该属性,从而完成序列化 而不是简单的在pojo是Seckill类上implements Serialization class对象代表seckill.class这个类的字节码对象 通过反射能够拿到这个字节码的属性和方法 RuntimeSchema就是基于这个创建了一个schema模式 当创建一个对象的时候,schema会根据你的模式赋予相应的值查看全部
-
jedis命名规则 缓存名:+id String key = "seckill:"+seckillId;查看全部
-
java访问redis的客户端 -- jedis查看全部
-
redis 官网 https://redis.io/download查看全部
-
详情页暴露接口,静态化放到cdn中,但每个公司的cdn不同,调用的api也就不一样,这里不详述 系统时间 只是new个日期对象返回,很快 所以不用优化 倒计时服务 在js端浏览器中,对服务器没有影响 地址暴露接口,所有的秒杀单在去可以秒杀的这个条件达成的时候,都要通过resetful的请求访问后端 也就是这里是个高并发的点 执行秒杀的操作,高并发 然后返回结果 通过这张图 优化重点在地址暴露接口和执行秒杀操作 由于地址暴露接口是根据这个秒杀时间来计算是否开启/是否结束/是否在秒杀中,所以不方便 作为cdn的内容来作为缓存,要放到服务器端,通过服务器逻辑来控制 同时因为这个接口调用的很频繁,所以不希望让它频繁的访问数据库 所以,这里使用redis优化地址暴露接口查看全部
-
cdn 将静态资源推到cdn查看全部
-
第一种方案在中小公司中很难实现,因为需要团队去支撑 成本高 第二种方案很普遍查看全部
-
判断update更新库存成功查看全部
-
如果tomcat部署在北京 mysql部署在上海 那么一次sql不考虑执行时间,光发过去再返回来就需要13~20毫秒 20毫秒意味着qbs最高也就是50查看全部
举报
0/150
提交
取消