楼主你可以考虑MYSQL的事务处理功能。
创新互联公司一直通过网站建设和网站营销帮助企业获得更多客户资源。 以"深度挖掘，量身打造，注重实效"的一站式服务，以成都网站制作、网站设计、外贸网站建设、移动互联产品、全网营销推广服务为核心业务。10多年网站制作的经验，使用新网站建设技术，全新开发出的标准网站，不但价格便宜而且实用、灵活，特别适合中小公司网站制作。网站管理系统简单易用，维护方便，您可以完全操作网站资料，是中小公司快速网站建设的选择。
一般来说，事务是必须满足4个条件（ACID）
原子性（Autmic）：事务在执行性，要做到“要么不做，要么全做！”，就是说不允许事务部分得执行。即使因为故障而使事务不能完成，在rollback时也要消除对数据库得影响！
一致性（Consistency）：事务得操作应该使使数据库从一个一致状态转变倒另一个一致得状态！就拿网上购物来说吧，你只有即让商品出库，又让商品进入顾客得购物篮才能构成事务！
隔离性（Isolation）：如果多个事务并发执行，应象各个事务独立执行一样！
持久性（Durability）：一个成功执行得事务对数据库得作用是持久得，即使数据库应故障出错，也应该能够恢复！
说白了就是某一个用户进行兑换操作的时候，就把对应的数据表锁定死，只有等操作完成后才解锁。
提供2种方法
1 利用数据库 和session或者cookie来处理
2 利用 ACL 或者 autherisation 处理
PHP是运行与服务器端的脚本语言，实现了数据库与网页之间的数据交互。一个完整的PHP网站系统由以下几部分组成。
操作系统
网络中的 服务器也是一台计算机，因此需要操作系统。PHP有着良好的跨平台性，支持windows和Linux等操作系统
web服务器
当一台计算机中安装操作系统后，还需要安装web服务器才能进行http访问。常见的web服务器软件有Apache、IIS、Nginx等
数据库
用于网站数据的存储和管理。PHP支持多种数据库，包括MySQL、sql server，oracle。db2
PHP软件
用于解析PHP脚本文件、访问数据库等，是运行PHP代码所必须的软件。
浏览器
是浏览网页的客户端。由于PHP脚本是在服务器端运行的，因此通过浏览器看到的是经过PHP处理后的html结果。。Zend引擎：Zend整体用纯C实现，是PHP的内核部分，他将PHP代码翻译（词法、语法解析等一系列编译过程）为可执行opcode的处理并实现相应的处理方法、实现了基本的数据结构（如：hashtable、OO）、内存分配机制及管理、提供了相应的api方法供外部调用，是一切的核心，所有的外围功能均围绕Zend实现。
2、Extensions：围绕着Zend引擎，extensions通过组件式的方式提供各种基础服务，我们常见的各种内置函数（array系列）、标准库等都是通过extension来实现，用户也可以根据需要实现自己的extension的典型应用）。
3、Sapi：Sapi全称Server Application Programming Interface，也就是服务端应用编程接口，Sapi通过一系列钩子函数，使得PHP可以和外围交互数据，这是PHP非常优雅和成功的设计，通过sapi成功的将PHP本身和上层应用解耦隔离，PHP可以不再考虑如何针对不同应用进行兼容，而应用本身也可以针对自己的特点实现不同的处理方式。
4、上层应用：这就是我们平时编写的PHP程序，通过不同的spai方式得到各种各样的应用模式，如何通过webserver实现web应用、在命令行下已脚本方式运行等等。
不支持
在云领域我们常常会听到一个词：多租户。这个词在不同的语境中有着不同的含义。本文将介绍云平台中的多租户的概念以及实现多租户支持的思路。
什么是租户
刚开始接触这个概念时，你肯定感觉“租户”这个词怪怪的。但假设我们换个词，我相信你立即就有感觉了。这个词就是“客户”（这里的客户指的就是商业上面的客户）。
一个租户就是一个客户，比方我们开发的服务是给 XXX 企业使用的，那该企业就是我们的一个客户/租户；假设这个服务是面向互联网的，那么使用该服务的每一个互联网用户都是一个客户/租户。
为什么须要多租户支持
开发人员辛辛苦苦开发出一个服务。提供给了个人/企业使用，这样就完事了么？当然不应该仅仅是这样。我们开发出一个服务。最好是可以同一时候提供给多个个人/企业使用。并且这些客户最好是共享同一套服务执行时（Runtime），这样可以大大减少服务的运维成本：
服务执行时假设分开，则运维的成本与客户数成正比（比方更新部署大量客户的场景）
节省资源（将服务所需资源利用最大化：运维团队统一、硬件使用）
另外，这样也能够减少服务的开发成本：
我们仅仅须要考虑怎样实现单用户的服务逻辑：业务逻辑相应其全部客户都是同样的，不管什么客户来使用，程序提供的服务都是一样的。进一步说，在业务层面我们开发这个服务时理论上不须要考虑多客户支持，我们仅仅用关注该服务的业务逻辑怎样实现
多客户的管理功能能够进行统一：开发人员应该不用考虑客户管理功能，这部分应该是由云平台统一提供的
多租户场景举例
如果我们要开发的服务是一个博客平台，这个服务是面向互联网用户的，每一个互联网用户都是我们的客户（一个用户就是一个租户）。
在不支持多租户的环境中，为了隔离每一个用户的数据，至少我们在设计数据库表时会考虑大多数表都存在一个 user_id 字段。用于 CRUD 数据时使用该字段进行用户隔离。
比方如今的业务是“公布文章”。须要将文章数据保存在 article 表中，在实现时实际上我们关注了两件事情：
CRUD：这是业务逻辑实现的一部分
用户隔离：须要增加 user_id。做业务关联
1 是“纯”业务逻辑部分的实现。这是必须实现的；2 则是为了多用户博客平台而须要考虑的，这并非博客平台本身的业务逻辑。这里假设能得到平台的多租户支持，就不用考虑第 2 点了。这样能够将注意力集中于第 1 点业务逻辑实现上，这是很典型的一个多租户场景。
多租户支持
我们能够这样理解多租户支持：
从服务提供的角度看。我们开发的一个服务执行时能够同一时候提供给多个客户使用。而且客户之间的数据/状态是保持隔离的
从服务使用的角度看，我和你能够作为不同的客户同一时候使用同一个执行的服务，此时我们使用该服务完毕的业务是相互不影响的，就好像我们在使用自己独享的服务一样
那么这个服务就是支持多“客户”的，即该服务支持多租户。这里的“服务”能够是应用，能够是 SaaS 平台，也能够是 PaaS 平台。只是按眼下我们熟悉的云平台看，应用的多租户支持应该是最常规的。这是由于应用面向的是用户，这个群体是非常庞大的。
多租户支持从实现的角度看。“是一种软件架构技术”，之所以强调它是属于架构层面是由于要实现它必须在做技术架构时就要将其考虑在内。
一种租户模型
本文一开始我们提到使用“客户”来置换“租户”来理解租户的含义。再从“商业”这个方面来看的话，我们不难发现租户事实上就是其云环境中的商业模式实现的一部分。商业模式是多样的。这意味着租户的划分也是多样的。这里我们描写叙述当中一种可能的租户栈：
应用程序是提供给用户使用的，对于应用来说，用户就是它的租户（这一点业界比较统一）
SaaS 提供的服务是给应用开发商使用的，对于 SaaS 来说，应用开发商就是它的租户
PaaS 提供的服务是给应用系统使用的，对于 PaaS 来说。相关应用的组合就是它的租户
SaaS 和 PaaS 面向的是开发商、系统等非端用户角色。这一部分通常是由云平台开发人员决定的（捆绑商业模式）。特别是私有/企业云平台一般不会考虑形如“在 PaaS 平台上支持执行多个 SaaS 平台”这种场景。所以以下我们很多其它的是环绕“应用对多租户支持”进行讨论。
应用多租户
应用多租户的使用场景前面已经介绍过了。如今如果我们是一个云平台开发人员，为了满足支持应用支持多租户的需求，在云平台中我们须要提供以下几个支持：
租户管理：CRUD，统计
租户隔离/共享的服务：队列、缓存、数据库等
租户隔离的统计：日志、配额
这些支持能够分为两类：
租户的管理：不会直接面向应用的端用户。面向的是应用的运维。平台应该提供详细实现
租户数据/状态的隔离：从请求开始就应该能够区分这个请求是来自于哪个租户，请求处理时在调用链路上也须要带上租户上下文。数据的存取是依照租户隔离的。调用平台提供的服务时也是租户隔离的
第 1 点比较easy实现。这是一个业务模型方面的问题，能够依据业务域来抽象租户模型，比方企业应用通常是依照“组织机构”来区分租户的；
第 2 点是一个纯技术的需求。须要在平台技术实现上支持按“租户”的执行时隔离，我们强调的是隔离，由于在实现时我们要达到的目标就是隔离，仅仅只是这里是按租户（租户仅仅是一个商业概念，技术层面我们最好能够将其进行抽象。尽量减小商业模式多样化对技术架构的冲击）。我们能够将租户映射到一个抽象概念上，这个抽象概念能够实现我们的隔离需求。
