一种基于用户有限机会的线上房源锁定方法及系统与流程

本发明涉及房地产技术领域，具体涉及一种基于用户有限机会的线上房源锁定方法及系统。

背景技术：

近年来随着互联网技术的发展，房地产开始大量采用在线选房的方式进行销售。相比传统的线下开盘，线上销售具有节省成本，大数据分析，操作便捷等等优点。对于常见的销售活动，往往面临大量客户集中针对同一个房源进行抢购的场景，同时基于项目销售过程中每个客户的特性，不同用户还拥有数量不等的抢购机会数量。因此销售系统需要对抢购的房源、每个用户不同的抢购机会数量进行双重锁定，并以此为核心构建抢购逻辑才能保证系统的数据一致性及稳定性。

开发商在进行房源销售的过程中会对潜在的购房用户群体进行统一开盘销售活动，在面对用户进行房源选择的过程中，保证用户购买机会公平及房源公平的双重公平选择权公平性成为销售过程的重点工作。特别在利用互联网工具进行房源销售的过程中，系统的公平性更是开盘活动顺利进行的重要保证。

线上销售是一种利用互联网信息系统进行房地产房源销售的工具，是一种互联网电商平台在房地产销售领域的行业落地，特别是针对一些重点的楼盘房源，用户的购买行为会竞争非常激烈，因此如何防止一房多卖的问题一直是困扰此类系统的重要难题。线上销售系统在房地产的落地应用不仅仅是针对电商平台简单的在房地产行业的应用，常规的电商流程是不能满足复杂的房地产销售业务需求。

技术实现要素：

本发明提供了一种基于用户有限机会的线上房源锁定方法及系统，能够满多类客户在拥有不同的机会情况下进行房源的购买，同时又能够保证的每个房源的公平选择权利，提高用户的使用体验。

本发明采用如下技术方案：

一种基于用户有限机会的线上房源锁定方法，包括：

s1、获取用户使用登录账号发出的登录请求，其中，登录账号为开发商配置分配的登录账号；

s2、获取登录用户根据需要购买的项目搜索查看的房源信息、收藏的意向房源信息；

s3、为登录用户分配筹单号，其中，每一个筹单号代表了一个购买机会；

s4、当开始进入购买时间段时，获取用户的一次购买请求和请求发送的时间；

s5、验证用户是否有剩余的筹单号，若是，则进行步骤s6，若否，则提示用户购买已达到上限；

s6、根据不同用户的购买请求发送的时间顺序进行排列，将排在最前面的购买请求所对应的用户进行对意向房源的锁定，并生成对应的选房单；

s7、将意向房源的状态更改为已销售，并消减对应用户的筹单号。

进一步地，所述获取用户使用登录账号发出的登录请求之前，获取用户的微信授权、用户登录账号与微信账户的绑定关系。

进一步地，所述为登录用户分配筹单号中，不同用户拥有不同数量的筹单号。

进一步地，所述用户的一次购买请求是通过用户点击购买实现的对意向房源的一次购买请求。

一种基于用户有限机会的线上房源锁定系统，包括锁的生产服务器、数据库服务器、登录模块、获取模块、分配模块、请求模块、验证模块、排序模块、锁定生成模块、更改模块；

登录模块，用于获取用户使用登录账号发出的登录请求；

获取模块，用于获取登录用户搜索查看的房源信息、收藏的意向房源信息；

分配模块，用于为登录用户分配筹单号；

请求模块，用于获取用户的一次购买请求和请求发送的时间；

验证模块，用于验证用户是否有剩余的筹单号；

排序模块，用于对请求发送的时间顺序进行排列；

锁定生成模块，用于对用户进行对意向房源的锁定并生成对应的选房单；

更改模块，用于将意向房源的状态更改为已销售，消减对应用户的筹单号。

进一步地，所述验证模块通过全局唯一的筹单号去请求锁服务器的锁资源，若能请求到该锁，则用户具有购买机会，同时设定该锁的自动释放时间。

进一步地，所述锁定生成模块通过全局唯一的房源id去请求锁服务器的锁资源，若能请求到该锁，则用户具有购买该房源的资格，同时设定该锁的自动释放时间。

进一步地，所述自动释放时间设定为30s。

进一步地，所述锁的生产服务器为redis，利用redis的原子能力setnx操作进行锁的生成；所述数据库服务器为mysql，使用innodb作为数据库存储引擎。

进一步地，所述锁的生产服务器中锁的获取操作为原子操作。

本发明的有益效果为：集成了微信的授权体系和验证手段，保证了用户基于微信账户与销售系统账户的一一绑定，从而达到双向数据验证的方式定位真实的授权客户。在面对用户进行房源选择的过程中，同一个项目中不同用户基于自己的购买能力会拥有不同的购买机会，在同一个房源的购买过程中，每个机会之间的权力是平等独立的，实现了用户的购买机会公平和房源公平的双重公平选择权，能够保证用户进行抢购房源的公平性，并且能够防止一房多卖。且本方案的安全性和稳定性高，不会因为自身问题导致死锁的出现，并且具有针对死锁场景的自动恢复能力。

附图说明

图1为本发明实施例一的步骤示意图。

具体实施方式

下面结合附图对本发明作进一步的详细说明。

实施例一

本方案是基于微信平台进行的移动互联设备的h5应用，充分集成了微信的授权体系和验证手段，保证了用户基于微信账户与销售系统账户的一一绑定，从而达到双向数据验证的方式定位真实的授权客户，同时用户在销售开始时登录完成选房的操作以最终生成选房单作为凭据。

用户的在对房源购买的过程中需要逐一实现房源的查找，收藏，抢购等系列动作行为。而在抢购环节，系统需要根绝客户的机会和房源的销售状态进行系列操作从而判定房源最终的购买用户。

如图1所示，本实施例提供了一种基于用户有限机会的线上房源锁定方法，该方法具体包括以下步骤：

s1、获取用户使用登录账号发出的登录请求，其中，登录账号为开发商配置分配的登录账号。获取用户使用登录账号发出的登录请求之前，获取用户的微信授权、用户登录账号与微信账户的绑定关系。

s2、获取登录用户根据需要购买的项目搜索查看的房源信息、收藏的意向房源信息；

s3、为登录用户分配筹单号，不同用户拥有不同数量的筹单号。其中，每一个筹单号代表了一个购买机会，同时用户会查看到开发商为用户分配的筹单号。

s4、当开始进入购买时间段时，获取用户的一次购买请求和请求发送的时间。用户的一次购买请求是通过用户点击购买实现的对意向房源的一次购买请求。

s5、验证用户是否有剩余的筹单号，若是，则进行步骤s6，若否，则提示用户购买已达到上限。

s6、当判定用户具有购买房源的机会之后，会对该具体的房源继续请求购买行为，根据不同用户的购买请求发送的时间顺序进行排列，将排在最前面的购买请求所对应的用户进行对意向房源的锁定，并生成对应的选房单。

s7、当用户的选房单生成完成之后，将意向房源的状态更改为已销售，并消减对应用户的筹单号，即购买机会。

本实施例集成了微信的授权体系和验证手段，保证了用户基于微信账户与销售系统账户的一一绑定，从而达到双向数据验证的方式定位真实的授权客户。在面对用户进行房源选择的过程中，同一个项目中不同用户基于自己的购买能力会拥有不同的购买机会，在同一个房源的购买过程中，每个机会之间的权力是平等独立的，实现了用户的购买机会公平和房源公平的双重公平选择权，能够保证用户进行抢购房源的公平性，并且能够防止一房多卖。

实施例二

本实施例提供了一种基于用户有限机会的线上房源锁定系统，包括锁的生产服务器、数据库服务器、登录模块、获取模块、分配模块、请求模块、验证模块、排序模块、锁定生成模块、更改模块。

锁的生产服务器，选择redis作为锁的生产服务器，利用redis的原子能力setnx操作进行锁的生成，保证锁的获取操作为原子操作。

数据库服务器，选择mysql作为数据库服务器，其中选用innodb作为数据库存储引擎，mysql是一套具有事务能力的数据库服务器，能够保证事务的生成、提交、回滚的能力。

登录模块，用于获取用户使用登录账号发出的登录请求。

获取模块，用于获取登录用户搜索查看的房源信息、收藏的意向房源信息。

分配模块，用于为登录用户分配筹单号。

请求模块，用于获取用户的一次购买请求和请求发送的时间。

排序模块，用于对请求发送的时间顺序进行排列。

更改模块，用于将意向房源的状态更改为已销售，消减对应用户的筹单号。

验证模块，用于验证用户是否有剩余的筹单号。系统在用户首次验证是否具有购买机会的事件中，通过全局唯一的筹单号去请求锁服务器的锁资源，如果能请求到该锁，则用户具有购买机会，同时该锁设定释放时间为30s，从而避免系统的异常导致死锁的情况发生。

锁定生成模块，用于对用户进行对意向房源的锁定并生成对应的选房单。系统在用户验证是否能够购买房源的事件中，通过全局唯一的房源id去请求锁服务器的锁资源，如果能请求到该锁，则用户具有购买该房源的资格。同时该锁设定自动释放时间为30s，从而避免系统的异常导致死锁的情况发生。

系统对同时获取到机会锁和房源锁的用户进行选房单的生成及房源状态变更的系列操作，能够保证系列操作行为在同一个事务内，由事务来提供原子性、一致性、隔离性、持久性。

系统对完整实现了选房单的客户进行机会锁和房源锁的持久化处理，从而保证了不会再被其他用户进行请求。

本实施例的方案能够满足多类客户在拥有不同的机会情况下进行房源的购买，同时又保证了每个房源的公平选择权利，在系统稳定性方面也有显著的提升，不会因为自身问题导致死锁的出现，并且具有针对死锁场景的自动恢复能力。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解；其依然可以对前述实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明实施例技术方案的范围，其均应涵盖在本发明的权利要求和说明书的范围当中。