PostgreSQL 秒杀场景优化

秒杀场景的典型瓶颈在于对同一条记录的多次更新请求，然后只有一个或者少量请求是成功的，其他请求是以失败或更新不到告终。

例如，Iphone的1元秒杀，如果我只放出1台Iphone，我们把它看成一条记录，秒杀开始后，谁先抢到（更新这条记录的锁），谁就算秒杀成功。

例如：

使用一个标记位来表示这条记录是否已经被更新，或者记录更新的次数（几台Iphone）。

@H_301_14@update tbl set@H_301_14@ xxx=@H_301_14@xxx,@H_301_14@upd_cnt+1@H_301_14@ where@H_301_14@ idpk and@H_301_14@ upd_cnt1<=5;@H_301_14@ --@H_301_14@ 假设可以秒杀台

这种方法的弊端：

获得锁的用户在处理这条记录时，可能成功，也可能失败，或者可能需要很长时间，（例如数据库响应慢）在它结束事务前，其他会话只能等着。

等待是非常不科学的，因为对于没有获得锁的用户，等待是在浪费时间。

所以一般的优化处理方法是先使用for update nowait的方式来避免等待，即如果无法即可获得锁，那么就不等待。

begin;

select@H_301_14@ from@H_301_14@ tbl for@H_301_14@ update nowait如果用户无法即刻获得锁，则返回错误。从而这个事务回滚。

end;

这种方法可以减少用户的等待时间，因为无法即刻获得锁后就直接返回了。

但是这种方法也存在一定的弊端，对于一个商品，如果可以秒杀多台的话，我们用1条记录来存储多台，降低了秒杀的并发性。

因为我们用的是行锁。

解决这个问题办法很多，最终就是要提高并发性，例如：

1. 分段秒杀，把商品数量打散，拆成多个段，从而提高并发处理能力。

总体来说，优化的思路是减少锁等待时间，避免串行，尽量并行。

优化到这里就结束了吗？显然没有，以上方法任意数据库都可以做到，如果就这样结束怎么体现Postgresql的特性呢？

Postgresql还提供了一个锁类型，advisory锁，这种锁比行锁更加轻量，支持会话级别和事务级别。（但是需要注意ID是全局的，否则会相互干扰，也就是说，所有参与秒杀或者需要用到advisory lock的ID需要在单个库内保持全局唯一）

例子：

update tbl set xxx=xxxupd_cnt+1 where idpk and upd_cnt1<=5pg_try_advisory_xact_lock(:id);

最后必须要对比一下for update nowait和advisory lock的性能。

下面是在一台本地虚拟机上的测试。

新建一张秒杀表

@H_301_14@postgres=# \d t1

Table "public.t1"

Column | Type | Modifiers

--------+---------+-----------

id | integer | not null

info | text |

Indexes:

"t1_pkey" PRIMARY KEY,btree (id)

只有一条记录，不断的被更新

# select * from t1;

id | info

----+-------------------------------

1 | 2015-09-14 09:47:04.703904+08

(1 row)

PostgreSQL 秒杀场景优化

猜你在找的Postgre SQL相关文章