电商经典漏洞案例，新手电商必看的6大实话

本内容由系统网小编为大家分享，Windows系统安装教程、办公系统、软件怎么使用、软件使用教程、办公软件攻略等信息。

作为程序员,开发的方向可以大致分为两个领域:一个是商业架构,另一个是技术架构(中间件方向)。

企业架构以其核心关键字为主,主要围绕这些不同的商业场景和商业规则,完成企业系统的基础建设,并向用户提供在线信息服务。

就商业而言,有许多方向可以走,例如:旅行、外包、收费、O2O、内容、社会、新鲜食品、零售商、不同的商业都有不同的特征。

面对如此众多的业务领域, 没有一般技术经验可提取, 让我们举个百个.

这里,第一个推动电子业务的电子系统非常复杂,要求高协调、高性能、高可用性、高扩充等。

作为一个开发者,我希望成为一些业务领域的技术专家,最好先熟悉电子行业,具有很强的参考意义。

那么,在电子领域技术架构的共同问题是什么?

一、避免重复下单

用户快速指出两个“提交订单”按钮,然后浏览器向后端发送两个请求创建订单,最终创建两个相同的订单。

解决方案：

解决办法是使用一个功率等价机制,使得多个请求和一个请求是相同的。

方案一：

使用数据库本身的特性“主键仅限制”,在记录命令时插入主键值。如果命令重复,记录插入将失败。

操作过程：

介绍一种服务,以生成“一尺寸适合所有人的订单号码”

当输入订单页时,前端要求服务先生成订单ID

在提交订单时,请求参数与业务参数一起附有此预生成的订单ID

方案二：

通过js脚本控制,前端无法解决用户提交的更新请求,也无法解决恶意提交。

建议 不 通过 该 方案, 而是 只 作为 补充, 如果 要 使用 该 方案 。

方案三：

附加参数在协议前和之后被检查。

当用户单击“购买”按钮时,下页会显示货物、收据地址、货物、价格等信息,并嵌入网页Token用户提交订单时,后端业务逻辑检查符号,如果符号存在并匹配,则被认为是合理的请求。

注意：同一个Token你只能使用一次, 使用后马就失败了.

补充：

这些两篇文章中可以找到更多的功率等价处理的解决方案

如何在高连贯性下保证接口的功率等效性?

电力设计的技术方案是什么?

订购缩短存储成本

产品信息可以修改,当用户订购时,为了更好地解决可能的反向销售争端,订购的创建将同步存储产品细节信息,称为订购快照。

同一件商品，许多用户将购买,如果热销商品，不久,将有数以万计的订单。如果每个订单创建一个闪光图,存储成本太高。此外,虽然产品信息支持修改,但毕竟,这是一个低频运动。我们可以理解成，大多数订购的货物都有相同的照片信息,除非用户在提交时修改它。

如何在实时识别修改动作是解决快照成本的关键。 我们使用总结比较方法。 在创建订单时,检查产品信息摘要是否已经存在。

由于命令快照是非核心操作,即使失败也不会影响用户正常购买过程,因此使用异步过程执行是正常的。

购物车,混合储存

购物车是零售商系统的分类功能,临时用户想要购买商品。 它分为三个操作:添加产品,查看清单,和结算。

技术设计并不特别复杂,存储的信息相对有限(用户ID、产品ID、sku_id、数量、加时)。

当添加一个购物车时,后端检查用户是否登录,常规思维,引导用户跳上登录页,等待登录成功,然后再添加购物车。

如果你小心地体验北京、 Taobao等大型平台,你会发现即使你没有登录,也可以添加购物车,这怎么会真的发生呢?

该原则并不复杂,服务端端在用户登录核查的侧面,在用户不登录时进行分支路由,创建一个临时Token,作为用户唯一的标识符,购物车数据存储在Token接下来,为了避免购物车数据的相互作用和设计的复杂性,这里将是一个临时购物车时钟。

当然,临时购物车表没有大量数据,所以为什么用户不仅仅添加购物车,并且经常与它们一起玩呢? 当他们登录并查看他们的购物车时,服务将从请求的cookie中搜索它们Token查明和查询是否有有关临时购物车时钟的数据,然后将其合并到官方购物车时钟中。

特别说明：

临时购物车必须在服务端储存 吗? 不一定.

倾向于在浏览器中预储存数据的建筑师或APP LocalStorage数据的这一部分毕竟不是共享的,但它并不增加设计的复杂性。

客户端需要使用本地数据索引以远程请求完整的信息

如果您 logged in, 请添加数据合并逻辑

鉴于这两个数据只是用户识别上的差异,作者还建议将数据存储在一个单一服务器上,而且即使操作逻辑稍后发生变化,最终只能从操作系统中更改一个地方,而且良好的维护对我们来说也是很重要的。

四、库存超卖

一般 的 库存 扣除 方法 包括 :

订购减少库存:即买方订购后,减少对买家货物的总库存.减少库存的最简单的方法是减少下订单的库存,它也是最精确的控制方法之一,通过数据库的交易机制,在订购时直接控制货物的库存,不许过卖。但是你要知道，有些人可能无法支付账单。

付款减少库存:即买方订购后,并不立即减库存，只有用户付钱才能减少库存。否则库存将留给其他买家.但由于只有在付款时才能减少库存,如果并发比较高，买方可能在订购后不能付款,因为也许这些货物被别人买走了。

预储存库存:这个方法比较复杂,买家下单后，储存一定时间(例如30分钟),超过这个时间，库存将会自动释放，发行后,其他买家可以继续购买。在买家付款前，系统将检查订单库存是否有保留:如没有保留,如果库存不足(即扣减失败),则不准再付款;如果扣减成功,则不准再付款。然后完成付款,实际上减少库存.

关于减少库存的方法是更多业务层面考虑的,减少库存的核心是确保在请求大规模合并时数据库中的库存场值不负。

方案一：

它通常在使用行级锁以控制数据库引擎本身锁定记录,并通过where确保库存不会减少0下面是一个可以有效地控制过剩销售的场景。

方案二：

将数据库的字段数据设置为未签名整数,减少在库存字段值低于零时SQL文档的错误。

5,商船,物流账单更新ABA问题

举个例子：

商人把货物寄来,填上装运号,开始填上123号,后来发现是错误的,然后修改到456号。

现在,如果你打算在某一特定场景中埋葬一个错误,让我们看一下

过程：

启动“请求A”装运,调用订购服务接口,更新装运号码123

但反应有点慢,迟到了

这时,商人发现运费号码是错误的,于是启动了请求B更新运费号码到456订单服务也成功响应

此时,A请求启动了重新测试,再次调用订单服务,并更新了装运号码123订单服务也成功响应

订单服务的最后装运号码是123

不是个错误吗!

那么有什么好解决办法吗?

许多人可能会说,别再试一次,你知道吗重试机制它 是 对 高 可用性 服务 提供 的 一 项 重要 保障, 许多 重新 测试 由 框架 自动 开始 。

理想的解决方案：

数据库表引入一个额外的字段version每次更新时,表中的版本编号都会与请求参数所载的版本编号匹配

一致：才触发更新

不一致性:指定该期间数据更新已经执行,这可能会导致错误和拒绝执行。

担保交易的帐户余额续期

付款:我们必须从买方帐户减少一定金额,并增加一定金额到卖方帐户,以保证数据完整性、可追溯性当我们改变平衡时,我们通常同时插入一个记录流水。

帐户洪水关键字:洪水ID,金额,交易帐户,交易时间戳,订单号码,

注:帐户流只能添加,不能修改或删除。

之后,当系统进行会计时,我们只需要积累交易流程的详细数据,如果存在与资产负债表的差异,我们通常会使用交易流程来修正资产负债表的数据。

更新余额、记录流水尽管它属于两个业务,但一定要确保它们是成功的还是失败的。

数据库的交易隔离级别如下:读未提交（RU）、读已提交（RC）、可重复读（RR）、可串联

通常使用的隔离水平是RC和RR,因为这两个隔离水平可以避免脏读。

运行4个实验来解释MySQL的线锁,空隙锁..

InnoDB 解决幻读的方案 -- LBCC&MVCC

当然,如果涉及多个微服务调用,则将使用分布式交易

分布式交易是易于思考的一个大事务拆分为多个本地事务本地事务仍然由数据库本身的事务解决,而困难在于通过重新测试机制来解决这个分布一致性问题,以确保最终一致性是我们的常用解决方案。

MySQL读写分离导致的数据不一致

大部分的互联网业务是读多写少为了提高数据库群集的吞吐性能,我们通常使用主从架构、读写分离

部署主库实例,客户端请求所有写操作全部写入主库,然后使用MySQL自驱动器主从同步函数具有一些简单的配置,可以几乎实时同步从主存储器的数据多个从库实例主要的延迟非常小,通常不超过1毫秒。

客户端请求的所有读操作全部打到从库,使用多实例集群升级读请求的整体处理能力。

这个方案看起来是无缝的,但实际上有副作用

尽管主机在实时同步,但仍然有一个时间差主要的存储器数据刚刚更新,但数据尚未同步到存储器中,其次是读请求直接从图书馆访问, 看或旧数据, 影响用户体验.

任何事情都不是完美的,从主同步是相同的,没有完美的解决方案,我们必须找到平衡的妥协。

让我们拿一个消费电子公司为例,看看它是如何运作的产品层面来化解这个问题

为了测试实验的真正性,汤姆·科特在太保公司做了一次购物订单

在下面的确认页面上,单击“购买”按钮,然后进入“付款”页

输入支付密码,输入成功支付页面,页面有一个输入查看订单的细节。

点击查看交易详情跳到实际订单细节页面查看订单的付款状况(从存储库取的订单数据)

看懂了吗？

付款成功后,我们没直接跳进来订单详情页而不是添加一个不重要的中页(付款成功页)第一个是告诉你付款的结果是成功的,没有浪费钱,别担心;第二个是添加一些推荐的产品,提取网站的GMV。 最重要的是,我们增加了缓冲期命令主源数据同步争取了更多的时间。

这是一件好事,其他互联网企业也是如此。

那不是另一个教训吗?

八、历史订单，归档

根据第28条的规定,该系统将大部分的性能支出用于其业务的20%,数据并不是例外。在数据使用频率方面,企业经常访问的数据被称为热数据,而相反,它被称为冷数据。

了解数据的冷热特性后,它可以指导我们做一些目标的性能优化。这包括业务层面的优化,还有技术优化。比如：电商网站，一般只在3个月内查询订单,如果你想看看3个月前的订单,你需要访问历史订单页。

实现思路：

如何区分冷热数据? 为了结合商业思维,可能需要找到一个产品同学来共同讨论,以便作出决定,记住不要打头。

方案1:作为“停用时间”的标准,3个月前的订单数据将是冷数据,3个月的订单数据将是热数据。

选项2:根据“订单状态”字段,将完成的订单分开为冷数据和未完成的订单分开为热数据。

方案三：组合方式，把下单时间 > 3 个月且状态为 “已完结” 的订单标识为冷数据，其他的当作热数据。

如何触发冷热数据的分离

程序1:直接修改业务代码,在每个业务请求上触发冷热数据判断,取决于结果路径到相应的冷热数据表。 缺点:如果判断标准是时间维度数据已经过时,无法主动检测。

选项2:如果你觉得商业代码的修改是高度耦合的,那么再维护起来就不容易。 可以通过监测数据库更改日志的二进制方式来触发

备选方法3:通常在系统处于低压状态时,执行定时任务,并通过执行批量任务,将符合条件的冷数据转移到其他存储媒体。

3.如何实现冷热数据的分离,该过程大致分为三个步骤:

判断数据是否冷或热

将冷数据插入冷数据表

然后从原热库中删除传输数据

如何使用冷热数据

程序一:在设计接口时,将有可选的区别,例如上面的客户订单

选项2:直接在业务代码中分开。

订单分集表,多维查询

如果在网站上订货太多,我们通常会认为分库分表解决策略,没问题,方向是正确的。

但是查询维度很多

1、买家，查询我的订单列表，需要根据buyer_id来查询

2.欲查看订单详情,请参阅order_id来查询

3、卖家，查询我的销售列表，需要根据seller_id来查询

由于订单表只有一个表键, 如何满足多维SQL操作?

我们通常以买方尺寸为设计依据,下面的图是淘宝的订单列表

对于19号订单,我们发现与同一用户不同的订单的最后6个数字是相同的。 没错,这是用户ID的最后6个数字。

这样，上文中场景1、场景2查询可以复合提取,采用buyer_id或order_id的后六位作为分表键，对1 000 000建模, 获取买方尺寸的订单分数.

至于场景3在卖方维度的订单查询中,我们可以利用数据异质性,通过seller_id维度存储另一个数据,专门为卖方.

XTw.com.Cn系统网专业应用软件下载教程，免费windows10系统,win11,办公软件,OA办公系统,OA软件,办公自动化软件,开源系统,移动办公软件等信息，解决一体化的办公方案。