liubaixing

liubaixing 查看完整档案

填写现居城市  |  填写毕业院校  |  填写所在公司/组织填写个人主网站
编辑
_ | |__ _ _ __ _ | '_ \| | | |/ _` | | |_) | |_| | (_| | |_.__/ \__,_|\__, | |___/ 个人简介什么都没有

个人动态

liubaixing 赞了回答 · 2020-04-25

SQL 语句 NOT IN 和 != 如何优化?

not in 可以换成id > 8 ... union all ... id < 7
!= 也可以这样换,不过没看到你给userid加索引
或许可以用with优化,mysql不熟,
postgresql可以用explain analyse分析,共同学习吧

共同学习为什么要踩一下?不明白

explain analyse SELECT * FROM filemail.bottles WHERE id>8 AND userid != 34790331 AND show_times <= 10 AND status = 1
UNION ALL
SELECT * FROM filemail.bottles WHERE id<7 AND userid != 34790331 AND show_times <= 10 AND status = 1
ORDER BY reply_rate DESC, reward DESC
这样id的索引可以使用

QUERY PLAN
Index Scan using bottles_pkey on bottles (cost=0.29..117.04 rows=9
Index Cond: (id < 1000)
Total runtime: 0.352 ms

EXPLAIN

关注 2 回答 1

liubaixing 关注了用户 · 2020-04-10

CrazyCodes @crazycodes

https://github.com/CrazyCodes... 我的博客
_
| |__ __ _
| '_ | | | |/ _` |
| |_) | |_| | (_| |
|_.__/ \__,_|\__, |

         |___/   感谢生命可以让我成为一名程序员

                         CrazyCodes To Author

关注 4683

liubaixing 赞了文章 · 2020-04-10

电商系统设计之订单

timg?image&quality=80&size=b9999_10000&sec=1532631649974&di=1d2a5259543900a105826e512fb6e8a3&imgtype=0&data-original=http%3A%2F%2Fpic.cifnews.com%2Fupload%2F201503%2F23%2F201503230925232295.jpg

前言

用户交易将经历一段艰辛的历程,一般用户感觉不到,实际程序是经历了一段生死离别。具体付款流程如下

clipboard.png

不(wo)是(gu)这(yi)张(chuan)图(de),请看正经流程图

clipboard.png

之前的几篇文章介绍了

  • 购物车如何设计
  • 用户系统如何设计
  • 商品系统如何设计

其实他们都在为交易系统做铺垫,一个产品如果没有收入,那这只能是寺庙的公益产品。任何产品最终都要走向这步 (收钱)。

付款

用户付款过程中有很多场景也会出现意外,以下是我碰到的“天灾人祸”

成功

  • 用户发起微信支付并成功支付
  • 用户发起支付宝支付并成功支付
  • 用户发起银联支付并成功支付
  • 用户发起其他支付并成功支付

人祸

  • 用户发起微信支付但取消支付
  • 用户发起支付宝支付但取消支付
  • 用户发起银联支付但取消支付
  • 用户发起其他支付但取消支付

天灾

  • 用户发起微信支付“手机爆炸了”
  • 用户发起支付宝支付“瞬间没网了”
  • 用户发起银联支付“老婆来电话了”
  • 用户发起其他支付“老板进来了”

注释

遇到以上的情况,不要害怕、不要惊慌,并且不要“理会”,你只需要将这些操作记录下来即可。
正常我们都会将用户通过哪种支付方式存储到订单表中,方便查询。我想说这种做法没错,但是少了点什么,你应该有一张交易记录表,来记录用户发起了多少次支付,只有支付成功的时候方可记录到订单表中。这样做的优点有以下两点

  • 订单表是比较重要的,迫不得已尽量不要操作这张表,防止出现意外,订单表除了收货发货外一般没有其他需要操作的地方。
  • 可以记录每次用户发起支付的时间,通过所谓大数据分析用户对产品的需求度和认可度,如果用户多次发起付款但取消支付,那就说明(他没钱)他可能很期望得到,但是因为某种原因一直在犹豫,这个时候可以针对当前用户做优惠处理,例如发一张优惠券等等。

clipboard.png

表结构

交易表

CREATE TABLE `transaction` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `order_sn` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '交易单号',
  `member_id` bigint(20) NOT NULL COMMENT '交易的用户ID',
  `amount` decimal(8,2) NOT NULL COMMENT '交易金额',
  `integral` int(11) NOT NULL DEFAULT '0' COMMENT '使用的积分',
  `pay_state` tinyint(4) NOT NULL COMMENT '支付类型 0:余额 1:微信 2:支付宝 3:xxx',
  `source` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '支付来源 wx app web wap',
  `status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '支付状态 -1:取消 0 未完成 1已完成 -2:异常',
  `completion_time` int(11) NOT NULL COMMENT '交易完成时间',
  `note` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL COMMENT '备注',
  `created_at` timestamp NULL DEFAULT NULL,
  `updated_at` timestamp NULL DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `transaction_order_sn_member_id_pay_state_source_status_index` (`order_sn`(191),`member_id`,`pay_state`,`source`(191),`status`)
) ENGINE=InnoDB AUTO_INCREMENT=36 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

支付记录表

CREATE TABLE `transaction_record` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `order_sn` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL,
  `events` text COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '事件详情',
  `result` text COLLATE utf8mb4_unicode_ci COMMENT '结果详情',
  `created_at` timestamp NULL DEFAULT NULL,
  `updated_at` timestamp NULL DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=36 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

这个记录表可能让你匪夷所思,不知你对日志有什么概念,但我能说的就是,将用户的所有动作全部记录下来。这是很重要的,早晚你会懂。

订单表

CREATE TABLE `order` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `order_no` varchar(100) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '订单编号',
  `order_sn` varchar(100) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '交易号',
  `member_id` int(11) NOT NULL COMMENT '客户编号',
  `supplier_id` int(11) NOT NULL COMMENT '商户编码',
  `supplier_name` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '商户名称',
  `order_status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '订单状态 0未付款,1已付款,2已发货,3已签收,-1退货申请,-2退货中,-3已退货,-4取消交易',
  `after_status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '用户售后状态 0 未发起售后 1 申请售后 -1 售后已取消 2 处理中 200 处理完毕',
  `product_count` int(11) NOT NULL DEFAULT '0' COMMENT '商品数量',
  `product_amount_total` decimal(12,4) NOT NULL COMMENT '商品总价',
  `order_amount_total` decimal(12,4) NOT NULL DEFAULT '0.0000' COMMENT '实际付款金额',
  `logistics_fee` decimal(12,4) NOT NULL COMMENT '运费金额',
  `address_id` int(11) NOT NULL COMMENT '收货地址编码',
  `pay_channel` tinyint(4) NOT NULL DEFAULT '0' COMMENT '支付渠道 0余额 1微信 2支付宝',
  `out_trade_no` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL COMMENT '订单支付单号',
  `escrow_trade_no` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL COMMENT '第三方支付流水号',
  `pay_time` int(11) NOT NULL DEFAULT '0' COMMENT '付款时间',
  `delivery_time` int(11) NOT NULL DEFAULT '0' COMMENT '发货时间',
  `order_settlement_status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '订单结算状态 0未结算 1已结算',
  `order_settlement_time` int(11) NOT NULL DEFAULT '0' COMMENT '订单结算时间',
  `is_package` enum('0','1') COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '0' COMMENT '是否是套餐',
  `is_integral` enum('0','1') COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '0' COMMENT '是否是积分产品',
  `created_at` timestamp NULL DEFAULT NULL,
  `updated_at` timestamp NULL DEFAULT NULL,
  `deleted_at` timestamp NULL DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `order_order_sn_unique` (`order_sn`),
  KEY `order_order_sn_member_id_order_status_out_trade_no_index` (`order_sn`,`member_id`,`order_status`,`out_trade_no`(191))
) ENGINE=InnoDB AUTO_INCREMENT=44 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

运输

用户付款结束后接下来就是快递公司的事了,当然咱们不搭理送快递的。到这一步我们就应该给客户展示运输信息。现在一些api开放平台都有快递查询的服务,有收费有免费的,性能方面差异也不大。但这里要注意一点。不是每次用户都会查询到新的信息。对于小公司来说,这样成本极高。所以我们应该定时去查询快递物流信息。这个地方有个简单的算法。

if(用户点击查看了){
    从用户点击查看两小时后更新物流信息 // 这里是按照两小时来更新的,也可以拉长这个时间
}else{
    每两小时更新一次物流信息
}

这种频繁的更新绝对要使用nosql,当用户确认收货后再存储到mysql等数据库中。

收货

当用户收到货后,这其实是最难伺候的时候,用户对产品的各种不满意就可能导致退换货,收货操作既改变订单状态为已收货,复杂点的可能还需要im,短信,推送提醒下。一般都直接提醒,量大的话加入队列内处理。

退换货

退换货淘宝是这样处理的。
淘宝将订单分两种状态

  • 未付款、已付款、已收货、已评价
  • 发起售后、售后审核、售后处理、处理完成

clipboard.png

图1展示了每个商品,包括子商品都可以单独发起售后

clipboard.png

图2是点击申请售后之后的页面

clipboard.png

图3是选择退换货的相关事项

当完成这些步骤后,就会开启售后审核,卖家审核成功后方可进行下一步操作

售后申请表

CREATE TABLE `order_returns_apply` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `order_no` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '订单单号',
  `order_detail_id` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '子订单编码',
  `return_no` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '售后单号',
  `member_id` int(11) NOT NULL COMMENT '用户编码',
  `state` tinyint(4) NOT NULL COMMENT '类型 0 仅退款 1退货退款',
  `product_status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '货物状态 0:已收到货 1:未收到货',
  `why` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL COMMENT '退换货原因',
  `status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '审核状态 -1 拒绝 0 未审核 1审核通过',
  `audit_time` int(11) NOT NULL DEFAULT '0' COMMENT '审核时间',
  `audit_why` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL COMMENT '审核原因',
  `note` text COLLATE utf8mb4_unicode_ci COMMENT '备注',
  `created_at` timestamp NULL DEFAULT NULL,
  `updated_at` timestamp NULL DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

售后表

CREATE TABLE `order_returns` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `returns_no` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '退货编号 供客户查询',
  `order_id` int(11) NOT NULL COMMENT '订单编号',
  `express_no` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL COMMENT '物流单号',
  `consignee_realname` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '收货人姓名',
  `consignee_telphone` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '联系电话',
  `consignee_telphone2` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '备用联系电话',
  `consignee_address` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '收货地址',
  `consignee_zip` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '邮政编码',
  `logistics_type` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '物流方式',
  `logistics_fee` decimal(12,2) NOT NULL COMMENT '物流发货运费',
  `order_logistics_status` int(11) DEFAULT NULL COMMENT '物流状态',
  `logistics_settlement_status` int(11) DEFAULT NULL COMMENT '物流结算状态',
  `logistics_result_last` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL COMMENT '物流最后状态描述',
  `logistics_result` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL COMMENT '物流描述',
  `logistics_create_time` int(11) DEFAULT NULL COMMENT '发货时间',
  `logistics_update_time` int(11) DEFAULT NULL COMMENT '物流更新时间',
  `logistics_settlement_time` int(11) DEFAULT NULL COMMENT '物流结算时间',
  `returns_type` tinyint(4) NOT NULL DEFAULT '0' COMMENT '0全部退单 1部分退单',
  `handling_way` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT 'PUPAWAY:退货入库;REDELIVERY:重新发货;RECLAIM-REDELIVERY:不要求归还并重新发货; REFUND:退款; COMPENSATION:不退货并赔偿',
  `returns_amount` decimal(8,2) NOT NULL COMMENT '退款金额',
  `return_submit_time` int(11) NOT NULL COMMENT '退货申请时间',
  `handling_time` int(11) NOT NULL COMMENT '退货处理时间',
  `remark` text COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '退货原因',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

评价

如果用户收货后直接评价了,那恭喜你,这笔订单基本成交了。这个没什么可讲的,一般小的电商也没有刷评价的,类似淘宝的防止刷评价的做法太过于复杂,这里也不过多讲解(其实我也没接触过)。

评价数据表

CREATE TABLE `order_appraise` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `order_id` int(11) NOT NULL COMMENT '订单编码',
  `info` text COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '评论内容',
  `level` enum('-1','0','1') COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '级别 -1差评 0中评 1好评',
  `desc_star` tinyint(4) NOT NULL COMMENT '描述相符 1-5',
  `logistics_star` tinyint(4) NOT NULL COMMENT '物流服务 1-5',
  `attitude_star` tinyint(4) NOT NULL COMMENT '服务态度 1-5',
  `created_at` timestamp NULL DEFAULT NULL,
  `updated_at` timestamp NULL DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `order_appraise_order_id_index` (`order_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

致谢

感谢你看到这里,希望我的文章和代码可以帮助到你。如果有什么疑问可以在评论区留言,谢谢

查看原文

赞 167 收藏 125 评论 45

liubaixing 赞了文章 · 2019-05-07

多线程三分钟就可以入个门了!

前言

之前花了一个星期回顾了Java集合:

在写文章之前通读了一遍《Java 核心技术 卷一》的并发章节和《Java并发编程实战》前面的部分,回顾了一下以前写过的笔记。从今天开始进入多线程的知识点咯~

之前在学习Java基础的时候学多线程基础还是挺认真的,可是在后面一直没有回顾它,久而久之就把它给忘掉得差不多了..在学习JavaWeb上也一直没用到多线程的地方(我做的东西太水了...)。

由于面试这一部分是占很大比重的,并且学习多线程对我以后的提升也是很有帮助的(自以为)。

我其实也是相当于从零开始学多线程的,如果文章有错的地方还请大家多多包含,不吝在评论区下指正呢~~

一、初识多线程

1.1介绍进程

讲到线程,又不得不提进程了~

进程我们估计是很了解的了,在windows下打开任务管理器,可以发现我们在操作系统上运行的程序都是进程:

进程的定义:

进程是程序的一次执行,进程是一个程序及其数据在处理机上顺序执行时所发生的活动,进程是具有独立功能的程序在一个数据集合上运行的过程,它是系统进行资源分配和调度的一个独立单位
  • 进程是系统进行资源分配和调度的独立单位。每一个进程都有它自己的内存空间和系统资源

1.2回到线程

那系统有了进程这么一个概念了,进程已经是可以进行资源分配和调度了,为什么还要线程呢

为使程序能并发执行,系统必须进行以下的一系列操作:

  • (1)创建进程,系统在创建一个进程时,必须为它分配其所必需的、除处理机以外的所有资源,如内存空间、I/O设备,以及建立相应的PCB;
  • (2)撤消进程,系统在撤消进程时,又必须先对其所占有的资源执行回收操作,然后再撤消PCB;
  • (3)进程切换,对进程进行上下文切换时,需要保留当前进程的CPU环境,设置新选中进程的CPU环境,因而须花费不少的处理机时间。

可以看到进程实现多处理机环境下的进程调度,分派,切换时,都需要花费较大的时间和空间开销

引入线程主要是为了提高系统的执行效率,减少处理机的空转时间和调度切换的时间,以及便于系统管理。使OS具有更好的并发性

  • 简单来说:进程实现多处理非常耗费CPU的资源,而我们引入线程是作为调度和分派的基本单位(取代进程的部分基本功能【调度】)。

那么线程在哪呢??举个例子:

也就是说:在同一个进程内又可以执行多个任务,而这每一个任务我就可以看出是一个线程

  • 所以说:一个进程会有1个或多个线程的

1.3进程与线程

于是我们可以总结出:

  • 进程作为资源分配的基本单位
  • 线程作为资源调度的基本单位,是程序的执行单元,执行路径(单线程:一条执行路径,多线程:多条执行路径)。是程序使用CPU的最基本单位。

线程有3个基本状态

  • 执行、就绪、阻塞

线程有5种基本操作

  • 派生、阻塞、激活、 调度、 结束

线程的属性:

  • 1)轻型实体;
  • 2)独立调度和分派的基本单位;
  • 3)可并发执行;
  • 4)共享进程资源。

线程有两个基本类型

  • 1) 用户级线程:管理过程全部由用户程序完成,操作系统内核心只对进程进行管理。
  • 2) 系统级线程(核心级线程):由操作系统内核进行管理。操作系统内核给应用程序提供相应的系统调用和应用程序接口API,以使用户程序可以创建、执行以及撤消线程。

值得注意的是:多线程的存在,不是提高程序的执行速度。其实是为了提高应用程序的使用率,程序的执行其实都是在抢CPU的资源,CPU的执行权。多个进程是在抢这个资源,而其中的某一个进程如果执行路径比较多,就会有更高的几率抢到CPU的执行权

1.4并行与并发

并行:

  • 并行性是指同一时刻内发生两个或多个事件。
  • 并行是在不同实体上的多个事件

并发:

  • 并发性是指同一时间间隔内发生两个或多个事件。
  • 并发是在同一实体上的多个事件

由此可见:并行是针对进程的,并发是针对线程的

1.5Java实现多线程

上面说了一大堆基础,理解完的话。我们回到Java中,看看Java是如何实现多线程的~

Java实现多线程是使用Thread这个类的,我们来看看Thread类的顶部注释

通过上面的顶部注释我们就可以发现,创建多线程有两种方法:

  • 继承Thread,重写run方法
  • 实现Runnable接口,重写run方法

1.5.1继承Thread,重写run方法

创建一个类,继承Thread,重写run方法


public class MyThread extends Thread {

    @Override
    public void run() {
        for (int x = 0; x < 200; x++) {
            System.out.println(x);
        }
    }

}

我们调用一下测试看看:


public class MyThreadDemo {
    public static void main(String[] args) {
        // 创建两个线程对象
        MyThread my1 = new MyThread();
        MyThread my2 = new MyThread();

        my1.start();
        my2.start();
    }
}

1.5.2实现Runnable接口,重写run方法

实现Runnable接口,重写run方法


public class MyRunnable implements Runnable {

    @Override
    public void run() {
        for (int x = 0; x < 100; x++) {
            System.out.println(x);
        }
    }

}

我们调用一下测试看看:


public class MyRunnableDemo {
    public static void main(String[] args) {
        // 创建MyRunnable类的对象
        MyRunnable my = new MyRunnable();

        Thread t1 = new Thread(my);
        Thread t2 = new Thread(my);

        t1.start();
        t2.start();
    }
}

结果还是跟上面是一样的,这里我就不贴图了~~~

1.6Java实现多线程需要注意的细节

不要将run()start()搞混了~

run()和start()方法区别:

  • run():仅仅是封装被线程执行的代码,直接调用是普通方法
  • start():首先启动了线程,然后再由jvm去调用该线程的run()方法。

jvm虚拟机的启动是单线程的还是多线程的?

  • 是多线程的。不仅仅是启动main线程,还至少会启动垃圾回收线程的,不然谁帮你回收不用的内存~

那么,既然有两种方式实现多线程,我们使用哪一种???

一般我们使用实现Runnable接口

  • 可以避免java中的单继承的限制
  • 应该将并发运行任务和运行机制解耦,因此我们选择实现Runnable接口这种方式!

二、总结

这篇主要是讲解了线程是什么,理解线程的基础对我们往后的学习是有帮助的。这里主要是简单的入了个门

在阅读顶部注释的时候我们发现有”优先级“、”后台线程“这类的词,这篇是没有讲解他们是什么东西的~所以下一篇主要讲解的是Thread的API~敬请期待哦~

使用线程其实会导致我们数据不安全,甚至程序无法运行的情况的,这些问题都会再后面讲解到的~

之前在学习操作系统的时候根据《计算机操作系统-汤小丹》这本书也做了一点点笔记,都是比较浅显的知识点。或许对大家有帮助~

参考资料:

  • 《Java 核心技术卷一》
  • 《Java并发编程实战》
  • 《计算机操作系统-汤小丹》
如果文章有错的地方欢迎指正,大家互相交流。习惯在微信看技术文章,想要获取更多的Java资源的同学,可以关注微信公众号:Java3y。为了大家方便,刚新建了一下qq群:742919422,大家也可以去交流交流。谢谢支持了!希望能多介绍给其他有需要的朋友

文章的目录导航

查看原文

赞 13 收藏 9 评论 1

liubaixing 赞了回答 · 2019-02-13

解决如何理解向上转型

你这是父类的引用指向子类的对象,是java多态的体现。根据“编译看左边,运行看右边”的原则,编译时认为Person对象有dri()方法,不报错,运行时则因为p实际是一个Son对象,而执行Son的dri方法。其实向上转型,丢失的是子类独有的方法,而同名方法,则不会丢失,这也是interface的意义啊。

关注 2 回答 1

liubaixing 收藏了文章 · 2019-02-13

都9102年了,还问GET和POST的区别

1 前言

最近看了一些同学的面经,发现无论什么技术岗位,还是会问到 get 和 post 的区别,而搜索出来的答案并不能让我们装得一手好逼,那就让我们从 HTTP 报文的角度来撸一波,从而搞明白他们的区别。

2 标准答案

在开撸之前吗,让我们先看一下标准答案长什么样子 w3school: GET 对比 POST。标准答案很美好,但是在面试的时候把下面的表格甩面试官一脸,估计会装逼不成反被*。

分类GETPOST
后退按钮/刷新无害数据会被重新提交(浏览器应该告知用户数据会被重新提交)。
书签可收藏为书签不可收藏为书签
缓存能被缓存不能缓存
编码类型application/x-www-form-urlencodedapplication/x-www-form-urlencoded 或 multipart/form-data。为二进制数据使用多重编码。
历史参数保留在浏览器历史中。参数不会保存在浏览器历史中。
对数据长度的限制是的。当发送数据时,GET 方法向 URL 添加数据;URL 的长度是受限制的(URL 的最大长度是 2048 个字符)。无限制。
对数据类型的限制只允许 ASCII 字符。没有限制。也允许二进制数据。
安全性与 POST 相比,GET 的安全性较差,因为所发送的数据是 URL 的一部分。在发送密码或其他敏感信息时绝不要使用 GET !POST 比 GET 更安全,因为参数不会被保存在浏览器历史或 web 服务器日志中。
可见性数据在 URL 中对所有人都是可见的。数据不会显示在 URL 中。

注意,并不是说标准答案有误,上述区别在大部分浏览器上是存在的,因为这些浏览器实现了 HTTP 标准。

所以从标准上来看,GET 和 POST 的区别如下:

  • GET 用于获取信息,是无副作用的,是幂等的,且可缓存
  • POST 用于修改服务器上的数据,有副作用,非幂等,不可缓存

但是,既然本文从报文角度来说,那就先不讨论 RFC 上的区别,单纯从数据角度谈谈。

3 GET 和 POST 报文上的区别

先下结论,GET 和 POST 方法没有实质区别,只是报文格式不同。

GET 和 POST 只是 HTTP 协议中两种请求方式,而 HTTP 协议是基于 TCP/IP 的应用层协议,无论 GET 还是 POST,用的都是同一个传输层协议,所以在传输上,没有区别。

报文格式上,不带参数时,最大区别就是第一行方法名不同

POST方法请求报文第一行是这样的 POST /uri HTTP/1.1 \r\n

GET方法请求报文第一行是这样的 GET /uri HTTP/1.1 \r\n

是的,不带参数时他们的区别就仅仅是报文的前几个字符不同而已

带参数时报文的区别呢? 在约定中,GET 方法的参数应该放在 url 中,POST 方法参数应该放在 body 中

举个例子,如果参数是 name=qiming.c, age=22。

GET 方法简约版报文是这样的

GET /index.php?name=qiming.c&age=22 HTTP/1.1
Host: localhost

POST 方法简约版报文是这样的

POST /index.php HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded

name=qiming.c&age=22

现在我们知道了两种方法本质上是 TCP 连接,没有差别,也就是说,如果我不按规范来也是可以的。我们可以在 URL 上写参数,然后方法使用 POST;也可以在 Body 写参数,然后方法使用 GET。当然,这需要服务端支持。

4. 常见问题

GET 方法参数写法是固定的吗?

在约定中,我们的参数是写在 ? 后面,用 & 分割。

我们知道,解析报文的过程是通过获取 TCP 数据,用正则等工具从数据中获取 Header 和 Body,从而提取参数。

也就是说,我们可以自己约定参数的写法,只要服务端能够解释出来就行,一种比较流行的写法是 http://www.example.com/user/name/chengqm/age/22

POST 方法比 GET 方法安全?

按照网上大部分文章的解释,POST 比 GET 安全,因为数据在地址栏上不可见。

然而,从传输的角度来说,他们都是不安全的,因为 HTTP 在网络上是明文传输的,只要在网络节点上捉包,就能完整地获取数据报文。

要想安全传输,就只有加密,也就是 HTTPS。

GET 方法的长度限制是怎么回事?

在网上看到很多关于两者区别的文章都有这一条,提到浏览器地址栏输入的参数是有限的。

首先说明一点,HTTP 协议没有 Body 和 URL 的长度限制,对 URL 限制的大多是浏览器和服务器的原因。

浏览器原因就不说了,服务器是因为处理长 URL 要消耗比较多的资源,为了性能和安全(防止恶意构造长 URL 来攻击)考虑,会给 URL 长度加限制。

POST 方法会产生两个TCP数据包?

有些文章中提到,post 会将 header 和 body 分开发送,先发送 header,服务端返回 100 状态码再发送 body。

HTTP 协议中没有明确说明 POST 会产生两个 TCP 数据包,而且实际测试(Chrome)发现,header 和 body 不会分开发送。

所以,header 和 body 分开发送是部分浏览器或框架的请求方法,不属于 post 必然行为。

5 talk is cheap show me the code

如果对 get 和 post 报文区别有疑惑,直接起一个 Socket 服务端,然后封装简单的 HTTP 处理方法,直接观察和处理 HTTP 报文,就能一目了然

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import socket

HOST, PORT = '', 23333


def server_run():
    listen_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    listen_socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
    listen_socket.bind((HOST, PORT))
    listen_socket.listen(1)
    print('Serving HTTP on port %s ...' % PORT)
    while True:
        # 接受连接
        client_connection, client_address = listen_socket.accept()
        handle_request(client_connection)


def handle_request(client_connection):
    # 获取请求报文
    request = ''
    while True:
        recv_data = client_connection.recv(2400)
        recv_data = recv_data.decode()
        request += recv_data
        if len(recv_data) < 2400:
            break

    # 解析首行
    first_line_array = request.split('\r\n')[0].split(' ')

    # 分离 header 和 body
    space_line_index = request.index('\r\n\r\n')
    header = request[0: space_line_index]
    body = request[space_line_index + 4:]

    # 打印请求报文
    print(request)

    # 返回报文
    http_response = b"""\
HTTP/1.1 200 OK

<!DOCTYPE html>
<html>
<head>
    <title>Hello, World!</title>
</head>
<body>
<p style="color: green">Hello, World!</p>
</body>
</html>
"""
    client_connection.sendall(http_response)
    client_connection.close()


if __name__ == '__main__':
    server_run()

上面代码就是简单的打印请求报文然后返回 HelloWorld 的 html 页面,我们运行起来

[root@chengqm shell]# python httpserver.py 
Serving HTTP on port 23333 ...

然后从浏览器中请求看看

image

打印出来的报文

image

然后就可以手动证明上述说法,比如说要测试 header 和 body 是否分开传输,由于代码没有返回 100 状态码,如果我们 post 请求成功就说明是一起传输的(Chrome/postman)。

image

又比如 w3school 里面说 URL 的最大长度是 2048 个字符,那我们在代码里面加上一句计算 uri 长度的代码

...
# 解析首行
first_line_array = request.split('\r\n')[0].split(' ')
print('uri长度: %s' % len(first_line_array[1]))
...

我们用 postman 直接发送超过 2048 个字符的请求看看

image

然后我们可以得出结论,url 长度限制是某些浏览器和服务器的限制,和 HTTP 协议没有关系。

到此,我们可以愉快地装逼了 :)

参考:

  1. 99%的人都理解错了HTTP中GET与POST的区别
  2. 关于HTTP GET 和 POST
  3. w3school: HTTP 方法:GET 对比 POST
  4. wikipedia: 超文本传输协议
  5. RFC 2068
查看原文

liubaixing 赞了文章 · 2019-02-13

思否官方祝各位社区开发者 2019 春节快乐

图片描述

今天是 SegmentFault 团队春节假期前的最后一天的工作日,提前两天安排大家放假,早日开启一年一度最重要的春节假期。

感谢过去的一年,社区里热爱技术的开发者对思否社区的支持,也感谢各位合作伙伴霸霸的大力资持,希望新的一年,我们继续合作,一起前行。过去的一年我们的团队在精简,不过我们各方面数据都有所上升。

  1. 单日超过 50 万开发者访问
  2. 超过 10 万付费开发者用户,其中讲堂的付费用户超过 5 万
  3. 诞生了数名月入过万的讲师和少数月入十万的讲师
  4. 非常多厂商技术团队入驻,具体数据还未统计
  5. 腾讯、百度、阿里等知名的科技公司厂商也开始在思否社区投放广告
  6. 我们格子广告这个实验性小产品在上线的这半年时间里也已经服务超过了 200 个开发者客户
  7. 我们也在 2018 年年底,协助微信官方组织了一次官方发起的小程序黑客马拉松,取得圆满成功

当然对于我们一个 10 来人的小团队来说,依然有非常非常多的挑战,做好和维护好一个纯粹的开发者社区并不是一件容易的事情,因为人手和精力的问题,也有很多做的不到位的地方。我们也希望能不断的有所突破,在 2019 年取得更好的成绩,服务好社区的开发者。

春节假期社区部分管理工作会稍有调整,第一次内容发布审核,审核时间可能会比平时会慢一些,但是每天都会有管理员进行一些审核。同时我们也鼓励开发者,看到不规范的社区内容及时举报。

Last 祝各位开发者春节快乐,新的一年如下图所说...嘿嘿嘿

祝各位SegmentFault社区开发者 2019 春节快乐

查看原文

赞 78 收藏 3 评论 40

liubaixing 赞了回答 · 2019-02-13

解决redis怎样更新值而不重置过期时间

你可以把过期时间查出来,更新后,再ttl进去啊。

关注 4 回答 3

liubaixing 赞了问题 · 2019-02-13

解决redis怎样更新值而不重置过期时间

问题描述:

//存放一个key,设置30秒过期
jedis.set("key", "value1");
jedis.expire("key", 30);

//如果再更新一下
jedis.set("key", "value2");//发现过期时间就取消了

请问:怎样更新值的同时,不影响最初的过期时间设置?谢谢大家!

关注 4 回答 3

liubaixing 收藏了问题 · 2019-02-13

redis怎样更新值而不重置过期时间

问题描述:

//存放一个key,设置30秒过期
jedis.set("key", "value1");
jedis.expire("key", 30);

//如果再更新一下
jedis.set("key", "value2");//发现过期时间就取消了

请问:怎样更新值的同时,不影响最初的过期时间设置?谢谢大家!

认证与成就

  • 获得 0 次点赞
  • 获得 1 枚徽章 获得 0 枚金徽章, 获得 0 枚银徽章, 获得 1 枚铜徽章

擅长技能
编辑

(゚∀゚ )
暂时没有

开源项目 & 著作
编辑

(゚∀゚ )
暂时没有

注册于 2018-12-11
个人主页被 20 人浏览