-
框架方案查看全部
-
使用存储过程：整个事务在MySQL端完成查看全部
-
jedis查看全部
-
mybatis调用存储过程查看全部
-
这套系统部署 可能 参与的角色查看全部
-
高并发优化方法以及总结（含测试）：http://blog.csdn.net/qq_33290787/article/details/51899042。 熟悉使用guava commonutils 等工具类。是多个项目千锤百炼出来的查看全部
-
-- 存储过程 (只在银行被大量的时候,互联网公司用的很少,但是在秒杀中用) -- 1.存储过程优化: 事务行级锁持有的时间（Mysql服务器执行sql十分快） -- 2.不要过渡依赖存储过程。 -- 3.简单的逻辑可以应用存储过程 -- 4.QPS:一个秒杀单6000/qps（不同秒杀单，不同行，不存在问题）查看全部
-
insert操作：主键（商品id，killPhone）很少产生冲突 => 不涉及行级锁 => 可以并发执行 => 极大降低了网络延迟 和 GC带来的影响。 update操作：rowLock。针对同一行数据需要串行化执行。 个人解释：假设10000人同时抢同一件商品，insert放在前面，每个请求事务的insert前半部分请求，可以并发的发送和执行（非串行化）。假设极端情况，大家的insert部分操作都走完了，都只剩下update（rowLock，串行化操作）时。 易得 => 阻塞的时间降低为原来一半左右。 如果是update在insert前面 => A B C等人的update请求同时被发送到mysql服务端，但由于update有rowLock，是串行化的操作，导致 B C等人 对 同一行数据的update操作 必须要 等到 A update insert 并 commit 释放 rowLock之后，才能执行。 而 如果是 insert 在 update 之前的话， 等待/阻塞的时间，就只有 update -> commit 这后半部分的时间。 综上所述：insert放在update前：降低了单个事务操作rowLock的持有时间 => 同一单位时间可执行的update操作（事务）就会更多。 => 系统的并发量也就更大了！ 本质：Java客户端阻塞代码段的不同 ① update - insert ：Java客户端代码阻塞在 update操作返回。因为需要等待前一事务commit释放rowLock并返回。 ② insert - update ：insert 能并发执行返回，代码阻塞在了后半部分的update返回上。这样事务之间需要等待的时间（主要：网络延迟+GC mysql和java执行时间太短不计）就会较方案①降低一半左右。查看全部
-
持有行级锁是在update上,释放锁是在commit(spring控制)，也就是锁持有时间是update和commit之间的时间。这个过程网络请求越少，锁持有时间就越短。 insert不涉及行解锁。 insert 会 锁表么？ 实际业务会很复杂 跨多个数据源的时候就不能简单用存储过程来解决 行级锁定的优点： ·当在许多线程中访问不同的行时只存在少量锁定冲突。 ·回滚时只有少量的更改。 ·可以长时间锁定单一的行。 行级锁定的缺点： ·比页级或表级锁定占用更多的内存。 ·当在表的大部分中使用时，比页级或表级锁定速度慢，因为你必须获取更多的锁。 ·如果你在大部分数据上经常进行GROUP BY操作或者必须经常扫描整个表，比其它锁定明显慢很多。 · 用高级别锁定，通过支持不同的类型锁定，你也可以很容易地调节应用程序，因为其锁成本小于行级锁定。查看全部
-
insert 与 update 之间的逻辑调整。（调整代码顺序 => insert失败就不用执行下面的update的操作 + 降低了rowLock持有的时间 => 优化的目的） insert ignore 主键冲突了，返回0. 成功返回1查看全部
-
瓶颈不在 java执行速度 和 Mysql的执行速度上。 主要的瓶颈在于：1、网络延迟 2、GC查看全部
-
超时的基础上维护redis与mysql的一致性：虽简单、但常用查看全部
-
秒杀单对象一般是不会变的。 废弃新建，不修改。 logic 不关心 对象 是 从哪儿来的。查看全部
-
protostuff 需要 标准的POJO ，String Long是不行的。查看全部
-
https://github.com/eishay/jvm-serializers/wiki 不同序列化方案对比 protobuf 升级版（社区）--protostuff查看全部
举报
0/150
提交
取消