短小实用的分布式图片存储方案

博主分享了一种经济实惠的分布式图片存储解决方案,通过IIS/Appache/tomcat/WCF部署,利用nginx进行反向代理,实现上传、删除、下载的独立处理,并通过URL规则实现分布式存储。此方案降低了对外部存储服务的依赖,减少了成本,同时提高了安全性。

最近为网站的图片存储问题烦,虽然上了cdn,由于每天交换的图片数据有几十G,一直一台服务器撑着,但还是经常资源不足,导致无法上传图片或者显示图片;开始的设计是用第三方的存储,但是一直等待对方接口的开发,拖延了3~4个月,最后报价是每年3w多费用,没舍得花,也不想自己的平台受其它人控制着,最后咬了下牙建立了自己比较简单实用的图片存储方案,发现比较实用,分享下,个人属于经济实惠和节约资源的一个方案吧;

  1. 先看好处
    1.1.技术简单,通过IIS/Appache/tomcat/WCF部署,这种c#、Asp、asp.net、java、php的上传、删除、下载程序开发简单,部署简单,维护也简单;
    1.2.节约成本,有磁盘空间的服务器都可以应用上,普通的PC服务器都可以架,只要有磁盘,不会占额外的网站流量(第三方存储如果想自己也保存原图,会占用额外带宽);
    1.3.分布式,是实际意义上的存储分布式,减少风险,增加安全;
    1.4.改造成本小,其实就是将上传、下载、删除的整个过程全部独立出来;
  2. 实现方法
    2.1.存储服务器,需要Web容器,哪个都不重要,只要实现图片的上传、删除、下载(包含生成缩略图---这地方稍微复杂点);
    2.2.前端服务器,建议还是linux(window下的nginx基本测试里都不好用),用nginx做反向代理,通过URL规则来确定请求分发到哪台后端的web服务器上;
    2.3.URL规则,其实和数据库分区一样,就看你要细到什么程度,譬如我是按城市切割和业务切割的,即使再大的量,只需要增加后端存储服务器数就可以了;譬如:《庭院深深 小区》有一张图片,url是
### 分布式事务实现方案与最佳实践 分布式事务是指在一个分布式系统中,为了保证多个独立操作的一致性而采取的一种技术手段。以下是几种常见的分布式事务解决方案及其具体实现方式: #### 1. **基于两阶段提交(Two-Phase Commit, 2PC)** 两阶段提交是一种经典的分布式事务协议,分为准备阶段和提交阶段。它通过协调者(Coordinator)控制参与者(Participants)的行为来完成事务的提交或回滚。 - 准备阶段:所有参与者向协调者发送准备好状态的消息。 - 提交阶段:如果所有参与者都准备就绪,则协调者发出正式提交指令;如果有任何一个参与者失败,则整个事务被回滚[^2]。 这种方案的优点在于能够严格保障数据一致性,但缺点是性能开销较大,并且存在单点故障的风险。 #### 2. **Seata 的分布式事务解决方案** Seata 是阿里巴巴开源的一款高效、易于使用的分布式事务框架,支持多种事务模式,包括 AT、TCC、SAGA 和 XA 模式[^4]。 - **AT 模式** 自动化补偿事务模式,开发者只需关注核心业务 SQL 即可。Seata 在执行这些 SQL 的过程中会自动生成对应的 undo log 并记录到数据库表中,在发生异常时利用该日志进行回滚操作。 - **TCC 模式** Try-Confirm-Cancel 模型,适用于复杂场景下的手动定义尝试、确认以及取消逻辑的情况。此方法灵活性高,适合于跨服务调用较多的应用环境[^3]。 - **SAGA 模式** 面向长流程编排设计的状态机引擎,允许将长时间运行的任务拆解成一系列短小的操作链路并逐一执行。一旦某个环节出现问题即可按照预设规则逐步撤销前面已完成的部分。 - **XA 模式** 基于标准接口实现的传统二阶提交协议扩展版本,兼容性强但效率较低。 ```java // 使用 Seata 开启全局事务示例代码 @GlobalTransactional(timeoutMills = 30000, name = "purchase-order") public void purchase(String userId, String commodityCode, int orderCount) { storageService.deduct(commodityCode, orderCount); accountService.debit(userId, amount); } ``` 以上是一个简单的 Spring Boot 应用程序片段,展示了如何借助 `@GlobalTransactional` 注解快速集成 Seata 来管理分布式事务。 #### 3. **消息队列中间件配合最终一致性的异步处理机制** 在这种架构下,各子系统的交互不再依赖同步 RPC 调用来完成,而是改由可靠的消息传递代替。当生产方成功投递了一条消息之后即认为当前步骤结束,后续消费端接收到这条通知后再继续自己的工作流直至全部达成目标为止[^1]。 这种方法虽然无法做到强实时约束条件下的绝对一致性效果,但对于大多数互联网应用场景来说已经足够满足需求了,而且具备较好的水平扩展能力。 --- ###
评论 3
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值